Java线程锁——深入理解Java虚拟机

 

高效并发是从JDK1.5到1.6的一个重要改进，HotSpot虚拟机开发团对在这个版本上花费了大量精力去实现各种锁优化技术，如适应性自旋，锁消除，锁粗化，轻量级锁和偏向锁等，这些技术都是为了在线程之间更高效的共享数据，以及解决竞争问题，从而提高程序的执行效率。

 

 

一.自选锁与自适应自旋

 

前面我们讨论互斥同步的时候，提到了互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入到内核态中完成，这些操作给系统的并发性带来了很大的压力。如果物理机器有一个以上的处理器，能让两个或以上的线程同时去并发执行，我们就可以让后面请求锁的那个线程“稍等一下”，但不放弃处理器的执行时间（不挂起），看看持有锁的线程是否很快就会释放锁。为了让线程“等待”，我们只需要让线程执行一个忙循环(自旋)，这项技术就是所谓的自旋锁。

 

注意：自旋锁在实现等待的时候实在白白的浪费处理器的资源，所以自选锁的等待时间必须要有一定的限度，如果自选超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程了。自旋次数的默认值是十次，用户可以通过虚拟机参数修改。

 

JDK1.6后的改进：JDK1.6后，自选锁的自旋时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。如果在同一个锁上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在进行中，那虚拟机就会认为这次等待也很有可能再次成功，进而它将允许自旋等待时间相对更长一些，比如100个循环。另外，如果对于某个锁，自旋很少成功获得过，那在以后获取这个锁时将可能直接略过自旋过程，直接挂起，以避免处理器资源浪费。

 

 

 

二.锁消除

 

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

 

如何判断是否需要锁消除？

如何判断是否锁消除对某个同步块的锁：锁消除主要判断依据来源于逃逸分析技术，如果判断一段代码中堆上的所有数据都不会逃逸出去(这里指的线程逃逸)，从而被其它线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无需进行了。

 

注意：我们的程序中有许多的同步措施都是编译器自己加上去的，我们的锁消除就是要消除掉那些编译器自己为了防止并发加上去的但是实际不存在并发问题的锁。下面看个例子:

 

上面这段代码，会被编译器自动优化成线面的样子：

 

 

首先我来解释一下为什么要优化：因为我们都知道java.lang.String类生成的对象是不可变的，所以每次进行“+”操作，都会在堆中创建一个新的String类对象，然后将引用指向它，这样，会使我们的GC压力很大，因为对象的量暴增。但是如果采用StringBuffer或StirngBuilder的话，就不会产生新对象，始终都是这一个对象，确实提高了小效率。

 

 

下面来说上例于锁消除的关系：我们都直到StringBuffer使线程安全的，为什么呢？因为每个StringBuffer.append()方法都有一个同步块，锁就是sb对象。虚拟机观察sb变量，很快就会发现它的作用域被限制在addStr方法之中，永远都不会发生逃逸，其它线程无法访问到它，因此，虽然这里有锁，但是可以安全的消除它，在即时编译之后，这段代码就会忽略掉所有同步而直接执行了。

 

 

三.锁粗化

 

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

 

频繁的加锁释放锁操作，直接导致了锁粗化的出现：

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

 

上面的例子就是这样，连续的append()方法就属于这类情况。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展(粗化)到整个操作序列的外部，以上例来说就是扩展到第一个append()操作之前和最后一个append()操作之后，这样只需要加一次锁就可以了。

 

 

四.轻量级锁

 

是补偿，不是替代！

首先强调一点，轻量级锁并不是用来替代代替重量级锁的，它的本意是使用CAS操作在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的消耗。

 

对象头回顾：

HotSpot的对象头分为两部分，第一部分是对象的自身运行时数据，包括HashCode，GC年龄分带，线程持有锁，偏向时间戳等，这部分数据的长度在32和64为的虚拟机中分别是32bit和64bit，官方称它为“Mark Word”，它时实现轻量级锁和偏向锁的关键。另外一部分用于存储该指向方法区的对象类型数据的指针，如果是数组对象的话，还会有一个部分用于存储数组长度。

 

对象头信息是与对象自身定义的数据无关的额外成本，考虑到虚拟机的空间效率，Mark被设计成一个非固定的数据存储结构，以便节省空间。例如在32位的HotSpot虚拟机中对象位锁定状态下，Mark Word的32位空间中的25bit用于存储对象哈希码(HashCode),4bit用来存储对象分带年龄，2bit用于存储锁标志位，1bit固定位0，在其他状态(轻量级锁定，重量级锁定，GC标记，可偏向)下对象的存储内容见下表：

 

 

 

加锁过程：

 

1.虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Work的拷贝，这时候线程堆栈与对象头的状态如下图：

 

2.然后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Rcord的指针。如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位将转变为“00”（轻量级锁）。

 

3.如果这个操作失败了，虚拟机首先会检查对象的Mark Word是否已经指向当前栈帧，如果是，那么就代表当前线程已经持有了改对象的“轻量级锁”，你就直接进入同步快执行，否则，说明这个锁对象已经被抢占了。如果两条以上的线程争用同一个锁，那轻量级锁就不再有效，要膨胀为重量级锁，所状态标志发生改变，Mark Word中存储的就是指向重量级锁的指针，后面等待锁的线程进入阻塞状态。

 

 

 

解锁过程：

解锁过程依然是通过CAS操作实现的，如果对象的Mark Word仍然指向着线程的锁记录，那就用CAS操作把对象当前的Mark Word和线程中赋值的Displaced Mark Word替换回来，如果替换成功，整个同步过程就完成了。如果替换失败，说明有其它线程尝试过获取改锁，那就要在释放锁的同时，唤起被挂起的线程。

 

轻量级锁的优劣势：

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

 

 

 

五.偏向锁

 

偏向锁的定义：

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

 

偏向锁的启用：

假设当虚拟机启用了偏向锁，那么，当锁对象第一次被线程获取的时候，虚拟机会把对象头的锁标志位设为“01”，即偏向模式。同时使用CAS操作把获取到这个锁的线程的ID记录到对象的Mark Word之中，如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不进行任何同步操作。

 

偏向锁的释放：

当有另一个线程去尝试获取这个锁时，偏向模式宣告结束。根据锁对象目前是否处于被锁状态，撤销偏向锁(Revoke Bias)后恢复到未锁定或轻量级锁状态，后续的同步操作就如同上面介绍的轻量级锁一样。

 

偏向线程锁的优劣势：

偏向线程锁可以提高当有同步但无竞争的程序性能。它同样是一个带有效益权衡性质的优化，也就是说，它并不一定总是对程序有利，如果程序中大多数锁总是被多个不同线程访问，那偏向模式就是多余的。

 

这时深入理解Java虚拟机的最后一部分内容，最后推荐大家读原著《深入理解Java虚拟机》 ——周志明