Java虚拟机——锁优化之自旋锁、锁消除、锁粗化、轻量级锁、偏向锁

从JDK5升级到JDK6后，HotSpot虚拟机开发团队在这个版本上花费了大量的资源去实现各种锁优化技术，如自适应自旋锁、锁消除、锁粗化、轻量级锁、偏向锁等，这些技术都是为了在线程之间更高效地共享数据及解决竞争问题，从而提高程序的执行效率。

自旋锁和自适应自旋

互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给Java虚拟机的并发性带来了很大的压力。同时，在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。

现在绝大多数的个人电脑和服务器都是多核处理器系统，如果物理机器有一个以上的处理器或者处理器核心，能让两个或两个以上的线程同时并行执行，我们就可以让后面请求锁的那个线程”稍等一会“，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程稍等，我们只需让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。

自旋锁指的就是尝试获取锁的线程获取不到不会立即阻塞，而是采用循环的方式去尝试获取锁。

自旋等待不能替代阻塞，且不说对处理器数量的要求，自旋等待本身虽然避免了线程切换的开销，但它还是要占用处理器时间的。

• 所以如果锁被占用的时间很短，自旋等待的效果就会非常好。
• 反之如果锁被占用的时间很长，那么自旋的线程只会白白消耗处理器资源，而不会做任何有价值的工作，会带来性能的浪费。

因此自旋等待的时间必须有一定的限度，如果自旋超过了一定的次数仍没成功获取锁，就应该使用传统的方式(阻塞)。自旋次数的默认值是十次，用户也可通过参数-XX：PreBlockSpin来字行更改自旋次数。

自旋锁在JDK1.4版本就被引入，不过默认是关闭的，在JDK1.6版本之后就改为默认开启了。

在JDK1.6版本中还对自旋锁做了一些优化，引入了自适应的自旋。

自适应意味着自旋的时间不是固定的了，而是由 前一次在同一个锁上花费的自旋时间 及 锁的拥有者的状态 来决定的。

如果是在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而允许自旋等待持续相对更长的时间。

另一方面，如果对于某个锁，自旋很少成功获得过锁，那么在以后要获取这个锁的时候将有可能会直接省略掉自旋的过程，以避免浪费处理器资源。

锁消除

锁消除是指虚拟机即时编译器在运行时，对一些代码要求同步，但是对被检测到不可能存在共享数据竞争的锁进行消除。

锁消除的主要判定依据来源于逃逸分析的数据支持（变量是否逃逸，对于虚拟机来说需要使用复杂的过程间分析才能确定）。如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然也就无需再进行。

锁粗化

原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变少，即使存在锁竞争，等待锁的线程也能尽可能快地拿到锁。

大多数情况下，上面的原则都是正确的，但是如果一系列的操作都是对同一个对象重复进行加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。

如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展(粗化)到整个操作序列的外部，如以下的代码，就是扩展到第一个append()操作之前直至最后一个append()操作之后，这样只需加锁一次就可以了。

public static void main(String[] agrgs){
   StringBuffer b=new StringBuffer();
   b.append("1");
   b.append("2");
   b.append("3");
}

轻量级锁

轻量级锁是JDK1.6时加入的新型锁机制，它名字中的“轻量级”是相对于使用操作系统互斥变量来实现的传统锁(重量级锁)而言的。

轻量级锁并不是用来代替重量级锁的，它设计的初衷是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥变量所产生的性能消耗。

要理解轻量级锁，必须要对HotSpot对象的内存布局（尤其是对象头部分）有所了解。

HotSpot的对象头分为两部分

• 第一部分用于存储对象自身的运行时数据，如哈希码、GC分代年龄等。这部分数据的长度在32位和64位的Java虚拟机中分别会占用32个或64个比特，官方成它为"Mark word"。这部分是实现轻量级锁和偏向锁的关键。
• 另一部分用于存储指向方法区对象类型数据的指针，如果是数组对象，还会有一个额外的部分用于存储数组长度。
  

轻量级锁的加锁过程：

1. 在代码即将进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在当前线程的栈帧中建立一个命为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝。
   

2. 虚拟机将使用CAS操作尝试把对象的Mark Word更新为指向Lock Record的指针。

   • 如果这个更新动作成功了，即代表该线程拥有了这个对象的锁，并且对象Mark Word的锁标志位将转变为“00”，表示此对象处于轻量级锁定状态。
   • 如果这个更新动作失败了，那就意味着至少存在一条线程与当前线程竞争获取该对象的锁。虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧。
     • 如果是，则说明线程已经拥有了这个对象的锁，那直接进入同步块继续执行就可以了。
     • 否则，就说明这个锁对象已经被其他线程抢占了。
       

3. 如果出现两条以上的线程争用同一个锁的情况，那轻量级锁就不再有效，必须要膨胀为重量级锁，锁标志变为“10”，此时Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也必须进入阻塞状态。

解锁过程也同样是通过CAS操作来进行的，如果对象的Mark Word仍然指向线程的锁记录，那就用CAS操作把对象当前的Mark Word和复制的Lock Record替换回来。

假如能够成功替换，那整个同步过程就顺利完成了；如果替换失败，则说明有其他线程尝试获取该锁，就要在释放锁的同时，唤醒被挂起的线程。

轻量级锁能提升程序同步性能的依据是“对于绝大部分的锁，在整个同步周期内都是不存在竞争的”这一经验法则。如果没有竞争，轻量级锁便能通过CAS操作成功避免了使用互斥量的开销；但如果存在锁竞争，除了互斥量的本身开销外，还额外发生了CAS操作的开销。因此在有竞争的情况下，轻量级锁反而会比传统的重量级锁更慢。

偏向锁

偏向锁也是JDK1.6中引入的一项锁优化措施，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。

轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量，偏向锁则是在无竞争的情况下将整个同步都消除掉，连CAS操作都不去做了。

偏向锁中的偏就是偏向的“偏”，它是意思就是这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁一直没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。

假设当前虚拟机启用了偏向锁（启用参数：-XX：+UseBiasedLocking），那么当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志设置为“01”、把偏向模式设置为“1”，表示进入偏向模式。同时使用CAS操作把获取到这个锁的线程ID记录在对象的Mark Word之中。如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如加锁、解锁、对Mark Word的更新操作等）。

一旦出现另外一个线程去尝试获取这个锁的情况，偏向模式马上就宣告结束。

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