syncronized与锁优化

syncronized的实现原理和应用

在Java中，最基本的互斥同步手段就是syncronized关键字，syncronized经过编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令。这两个指令都需要一个reference类型的参数来指明要加锁或者解锁的对象。Java中任何一个对象都可以作为锁。具体表现为以下三种形式：

• 对于普通同步方法，锁是当前实例的对象
• 对于静态同步方法，锁是当前类的Class对象
• 对于同步方法块，锁是synchronized括号里配置的对象

重量级锁

JVM基于进入和退出Monitor对象来实现方法同步和代码块同步。在JDK 1.6之前，监视器锁可以认为直接对应底层操作系统中的互斥量（mutex）。这种同步方式的成本非常高，Java的线程是映射到操作系统的原声线程之上的，使用mutex以及线程阻塞造成的线程挂起与调用，都会引起用户态到内核态的切换。因此，后来称这种锁为“重量级锁”。

锁优化

从JDK1.5到JDK1.6，HotSpot虚拟机团队花费了大量精力去实现各种锁优化技术，如 适应性自旋（Adaptive Spinning）、锁消除（Lock Elimination）、轻量级锁（Lightweight Locking）和 偏向锁（Biased Locking） 等。

自旋锁

如果共享数据的锁定状态只会持续很少的时间，那么为了这段时间挂起和恢复线程并不值得。多处理器环境下，我们可以让后面那个请求锁的线程“稍等一下”，但不放弃处理器的执行时间。为了达到这个目的，我们只需要让线程执行一个忙循环（自旋），即所谓的自旋锁。

自旋对处理器的数量有要求，同时，如果锁被占用的时间过长，自旋只白白消耗处理器资源。因此，自选等待时间必须有一定的限度。如果超过了这个限度，那么就应该按照传统方式去挂起线程了。

JDK1.6中默认开启了自旋，可以通过-XX:+UseSpinning参数来关闭或开启。自旋默认次数是10次，通过-XX:+PreBlockSpin可以更改自旋次数限制。

自适应自旋

如果在同一个锁对象上，自旋等待刚刚成功获取过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而允许自旋等待持续相对更长的时间，比如100个循环。反之，如果自选很少成功获得过，那么以后要获取这个锁时将可能省略掉自旋过程，以避免浪费处理器资源。

锁消除

锁消除是指虚拟机的即时编辑器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的判定依据主要来自于逃逸分析技术的支持。如果在一段代码中，判断堆上所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无法进行。

锁粗化

如果一系列连续操作都是对同一个对象反复的加锁和解锁，甚至加锁操作是出现在循环体内，那么即使没有线程竞争，频繁进行同步操作也会导致不必要的性能损耗。如果虚拟机探测到有这样一串零碎的操作都是对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部。

轻量级锁

轻量级锁的目的是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

HotSpot虚拟机对象头Mark Word：

存储内容	标志位	状态
对象hashcode、分代年龄信息	01	未锁定
指向锁记录的指针	00	轻量级锁定
指向重量级锁的指针	10	膨胀（重量级锁定）
	11	GC标记
偏向线程ID、偏向时间戳、对象分代年龄	01	可偏向

在进入同步块的时候，如果此同步对象没有被锁定（锁标志位为01），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word拷贝（Displaced Mark Word），这时候线程堆栈与对象头的状态如图所示：

轻量级锁CAS操作之前堆栈与对象的状态

然后，虚拟机会使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针。如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位（Mark Word的最后2bit）将转变为“00”，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图所示：

轻量级锁CAS操作之后堆栈与对象的状态

如果更新操作失败了，虚拟机会首先检查对象的Mark Word是否指向当前线程的栈帧，如果是，说明当前线程已经持有对象的锁。否则，说明存在锁竞争。此时会自旋尝试获取锁，如果仍然失败，轻量级锁不再有效，需要膨胀为重量级锁，锁标志位变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。

轻量级锁释放时，同样使用CAS操作。持有锁的线程会会通过CAS把对象当前的Mark Word和线程中复制的Displaced Mark Word替换回来。如果替换成功，整个同步过程就完成了。如果替换失败，说明有线程竞争过锁，需要在释放锁的同时，唤醒被挂起的线程。

如果没有竞争，轻量级锁使用CAS避免了互斥量带来的开销，但如果存在竞争，除了互斥量的开销外还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁会比传统的重量级锁更慢。

偏向锁

如果说轻量级锁是在无竞争的情况下使用CAS操作消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不做了。因此，偏向锁的目的是在只有一个线程执行同步块时进一步提高性能。

64位虚拟机下Mark Word的存储结构：

锁状态	25bit	31bit	1bit	4bit	1bit是否是偏向锁	2bit锁标志位
无锁	unused	hashcode			0	01
偏向锁	ThreadID（54bit）	Epoch（时间戳2bit）			1	01

获取偏向锁的过程：

1.访问Mark Word中偏向锁的标识是否设置成1，锁标志位是否为01——确认为可偏向状态。

2.如果为可偏向状态，则测试线程ID是否指向当前线程，如果是，进入步骤5，否则进入步骤3。

3.如果线程ID并未指向当前线程，则通过CAS操作竞争锁。如果竞争成功，则将Mark Word中线程ID设置为当前线程ID，然后执行5；如果竞争失败，执行4。

4.如果CAS获取偏向锁失败，则表示有竞争。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。

5.执行同步代码。

偏向锁的释放过程：

偏向锁的撤销在上述第四步骤中有提到。偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程不会主动去释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态，撤销偏向锁后恢复到未锁定（标志位为“01”）或轻量级锁（标志位为“00”）的状态。

偏向锁、轻量级锁的状态转化及对象Mark Word的关系

轻量级锁和偏向锁都是带有效益权衡性质的优化，也就是说，它们并不总是对程序运行有利，如果程序中大多数的锁总是被多个不同的线程访问，那偏向模式就是多余的。可以使用-XX:+UseBiasedLocking来禁止偏向锁优化

对比

锁	优点	缺点	适用场景
偏向锁	加锁和解锁不需要额外的消耗，和执行非同步方法相比仅存在纳秒级的差距	如果线程间存在锁竞争，会带来额外的锁撤销的消耗	适用于只有一个线程访问同步块场景
轻量级锁	竞争的线程不会阻塞，提高了程序的响应速度	如果始终得不到锁竞争的线程，使用自旋会消耗CPU	追求响应时间，同步块执行速度非常快
重量级锁	线程竞争不使用自旋	线程阻塞，响应时间缓慢	追求吞吐量，同步块执行速度较长

---

参考文献：

• 周志明：《深入理解Java虚拟机》
• 方腾飞，魏鹏，程晓明：《Java并发编程的艺术》