Java锁升级

深藏阁楼爱情的钟 2022-04-08 09:20 221阅读 0赞

前言：对象的对象头中的存放着synchronized用的锁信息，详细结构内容请看《[Java对象的内存布局][Java]》

### 锁的升级 ###

Java SE1.6为了减少获得锁和释放锁所带来的性能消耗，引入了“偏向锁”和“轻量级锁”，所以在Java SE1.6里锁一共有四种状态，无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态，它会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率，下文会详细分析。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BhbmdlMTk5MQ_size_16_color_FFFFFF_t_70][]

### 偏向锁 ###

Hotspot的作者经过以往的研究发现大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出同步块时不需要花费CAS操作来加锁和解锁，而只需简单的测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁，如果测试成功，表示线程已经获得了锁，如果测试失败，则需要再测试下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁），如果没有设置，则使用CAS竞争锁，如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程。

**偏向锁获取过：**

*  （1）访问Mark Word中偏向锁的标识是否设置成1，锁标志位是否为01——确认为可偏向状态。
 *  （2）如果为可偏向状态，则测试线程ID是否指向当前线程，如果是，进入步骤（5），否则进入步骤（3）。
 *  （3）如果线程ID并未指向当前线程，则通过CAS操作竞争锁。如果竞争成功，则将Mark Word中线程ID设置为当前线程ID，然后执行（5）；如果竞争失败，执行（4）。
 *  （4）如果CAS获取偏向锁失败，则表示有竞争。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。
 *  （5）执行同步代码。

**偏向锁的撤销**：偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着，如果线程不处于活动状态，则将对象头设置成无锁状态，如果线程仍然活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么重新偏向于其他线程，要么恢复到无锁或者标记对象不适合作为偏向锁，最后唤醒暂停的线程。

下图中的线程1演示了偏向锁初始化的流程，线程2演示了偏向锁撤销的流程：

[![偏向锁的撤销][E5_81_8F_E5_90_91_E9_94_81_E7_9A_84_E6_92_A4_E9_94_80.png]][E5_81_8F_E5_90_91_E9_94_81_E7_9A_84_E6_92_A4_E9_94_80.png 1]

关闭偏向锁：偏向锁在Java 6和Java 7里是默认启用的，但是它在应用程序启动几秒钟之后才激活，如有必要可以使用JVM参数来关闭延迟-XX：BiasedLockingStartupDelay = 0。如果你确定自己应用程序里所有的锁通常情况下处于竞争状态，可以通过JVM参数关闭偏向锁-XX:-UseBiasedLocking=false，那么默认会进入轻量级锁状态。

### 轻量级锁 ###

**轻量级锁加锁**：

*  在代码进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态，且偏向锁标识位为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁记录目前的Mark Word的拷贝（称为Displaced Mark Word） 
 *  拷贝mark word的作用：为了不想在lock与unlock这种底层操作上再加同步。
 *  修改Object mark word轻量级锁指针作用：告诉其他线程，该object monitor已被占用
 *  owner指向object mark word作用：在下面的运行过程中，识别哪个对象被锁住了。

**这时候堆栈与对象头的状态如下**

![20150418202529951][]

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

![20150418202548406][]

*  如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧。如果指向，说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明这个锁对象已经被其他线程抢占了。如果有两条以上的线程争用同一个锁，那轻量级锁就不再有效，要膨胀为重量级锁，锁标志的状态值变为”10”，Mark Word中存储的就是指向重量级（互斥量）的指针。

**轻量级锁解锁**：轻量级解锁时，会使用原子的CAS操作来将Displaced Mark Word替换回到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。下图是两个线程同时争夺锁，导致锁膨胀的流程图。  
[![轻量级锁][E8_BD_BB_E9_87_8F_E7_BA_A7_E9_94_81.png]][E8_BD_BB_E9_87_8F_E7_BA_A7_E9_94_81.png 1]

因为自旋会消耗CPU，为了避免无用的自旋（比如获得锁的线程被阻塞住了），一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。

### 重量级锁 ###

重量锁在JVM中又叫对象监视器（Monitor），它很像C中的Mutex，除了具备Mutex(0|1)互斥的功能，它还负责实现了Semaphore(信号量)的功能，也就是说它至少包含一个竞争锁的队列，和一个信号阻塞队列（wait队列），前者负责做互斥，后一个用于做线程同步。

## 锁的优缺点对比 ##

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

推荐阅读：从源码层面解释锁 [https://www.aimoon.site/blog/2018/05/21/biased-locking/][https_www.aimoon.site_blog_2018_05_21_biased-locking]

### 参考 ###

*  [http://ifeve.com/java-synchronized/][http_ifeve.com_java-synchronized]

[Java]: https://blog.csdn.net/pange1991/article/details/68486725
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BhbmdlMTk5MQ_size_16_color_FFFFFF_t_70]: /images/20220407/f86db4d44d71405db4708ff9e0028010.png
[E5_81_8F_E5_90_91_E9_94_81_E7_9A_84_E6_92_A4_E9_94_80.png]: http://ifeve.com/wp-content/uploads/2012/10/%E5%81%8F%E5%90%91%E9%94%81%E7%9A%84%E6%92%A4%E9%94%80.png
[E5_81_8F_E5_90_91_E9_94_81_E7_9A_84_E6_92_A4_E9_94_80.png 1]: /images/20220407/6568a83181334de790bf504f950e294d.png
[20150418202529951]: /images/20220407/af04542d4f0443f0b576c5034ad6c4cc.png
[20150418202548406]: /images/20220407/952dd367607f4c68b363c97656ebbe50.png
[E8_BD_BB_E9_87_8F_E7_BA_A7_E9_94_81.png]: http://ifeve.com/wp-content/uploads/2012/10/%E8%BD%BB%E9%87%8F%E7%BA%A7%E9%94%81.png
[E8_BD_BB_E9_87_8F_E7_BA_A7_E9_94_81.png 1]: /images/20220407/638824a45f534c3b81148ecf6c2f2eaf.png
[https_www.aimoon.site_blog_2018_05_21_biased-locking]: https://www.aimoon.site/blog/2018/05/21/biased-locking/
[http_ifeve.com_java-synchronized]: http://ifeve.com/java-synchronized/