高并发篇_8 Synchronized源码分析III

r囧r小猫 2022-10-07 10:44 228阅读 0赞

**田超凡**

**原创博文，仿冒必究，部分素材转载自****每特教育****蚂蚁课堂**

### 1 偏向锁原理 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwMDU2MzQx_size_16_color_FFFFFF_t_70][]

1.  1.  **什么是偏向锁**

**当单个线程多次重复获取相同的锁的时候(ObjectMonitor锁对象相同)，为了避免重复的获取锁而进行的基于锁复用的优化。也就是说，单个线程在没有其他线程跟其竞争锁的情况下，对于多次获取的锁是会直接复用的，不会每次都进行系统调用，只在第一次获取锁进行系统调用，后面重复获取锁会直接复用已经获取到的锁。**

1.  1.  **偏向锁实现原理**

**线程在开始执行synchronized代码块时，会先去查锁对象ObjectMonitor对象头Mark World中的锁状态标志，检查是不是已经是偏向锁(101)**

**如果已经是偏向锁，那么会直接复用，不会再重新进行偏向锁的获取和释放**

**如果不是偏向锁，那么会获取锁对象对象头Mark World中的当前获取到锁的线程id,检查线程id是否是当前线程的id**

**如果对象头中的线程id是当前线程id, 如果是，表示当前线程已经获取到了偏向锁，此时就不会重复获取偏向锁**

**如果对象头中的线程id不是当前线程id, 且没有其他线程和当前线程同时去竞争这把锁的情况下，当前线程会基于CAS(001,101)将锁状态从无锁改为偏向锁，将锁状态标志记录到ObjectMonitor锁对象对象头Mark World锁状态标识位中，同时将当前获取到偏向锁的线程id也记录到ObjectMonitor锁对象对象头MarkWorld当前获取到锁的线程owner中**

**当某个线程获取到偏向锁之后，如果有其他线程也来竞争这把锁，那么此时获取偏向锁一定是失败的(CAS机制保证了同一时刻只有一个线程能获取到偏向锁)，那么此时会将该偏向锁撤销，然后升级为轻量级锁并重新开始竞争，将对象头Mark World中的锁状态标志改为轻量级锁(000)，并更新当前获取到锁的线程id.**

### 2 偏向锁批量重偏向和批量撤销 ###

**批量重偏向：****当****某****个线****程****通****过创****建多****个锁对****象****获****取到偏向****锁****之后****，其他****线****程****也****创****建****相同乃至更多****数****量的同一****个锁对****象****来试图竞争锁****，****当创建的偏向锁对****象****数****量超****过****20****的****时****候****，就****会将****偏向****锁****原先****绑****定的****线****程****id****更新****为当****前创建的偏向****锁对****象****数****量超****过了****20****个****的****线****程****id****，也可以理解****为****偏向****锁****的偏向****目****标发****生了****批量改****变**

**批量撤****销****：在多****线****程****竞争剧****烈的情****况****下，使用偏向****锁将会****降低效率，于是****产****生了批量撤****销****机制。****当****某****个线****程通****过创****建多****个锁对****象****获****取到偏向****锁****之后，其他****线****程也****创****建相同乃至更多****数****量的同一****个锁对****象****来试图竞争锁****，****当锁对****象****数****量超****过****40****的****时****候****，此****时会认为****操作非法****，****将创****建的****偏向****锁对****象全部撤****销**

**注意：**

**通过JVM的默认参数值，可以自定义设置批量重偏向和批量撤销的阈值。**

**-XX:+PrintFlagsFinal****，在项目启动时即可输出JVM的默认参数值**

**intx BiasedLockingBulkRebiasThreshold   = 20** **默认偏向锁批量重偏向阈值**

**intx BiasedLockingBulkRevokeThreshold  = 40****默认偏向锁批量撤销阈值**

**当然我们可以通过-XX:BiasedLockingBulkRebiasThreshold和 -XX:BiasedLockingBulkRevokeThreshold 来手动设置阈值**

### 3 轻量级锁原理 ###

![20210619165306791.png][]

**轻量级锁底层是基于CAS算法实现的，轻量级锁运行在用户态，它的核心思想是：同一时刻只有一个线程能获取到CAS轻量级锁，其他没有获取到锁的线程则会不断进行循环重试，直至获取到轻量级锁的线程释放后重新竞争轻量级锁。轻量级锁的目的本身并不是为了替代重量级锁，而是为了避免频繁进行系统调用而导致效率降低**

**轻量级锁在JVM中的实现机制：**

**(1)** **创建锁记录（Lock Record）对象，每个线程的栈帧（方法）都会包含一个锁记录的结构，内部可以储存锁定关联对象的Mark Word**

**(2)** **锁记录中Object reference （对象引用）指向锁对象，采用CAS算法 替换Object锁对象的Mark Word，将Mark Word 的值存入锁记录**

**(3)** **如果CAS执行成功，则对象头中存储了锁记录地址和状态00，表示该线程获取到轻量级锁**

### 4 重量级锁原理 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwMDU2MzQx_size_16_color_FFFFFF_t_70 1][]

**当某个线程获取到CAS轻量级锁之后，其他尝试获取锁的线程都会失败，不断进行重试，而不断重试是非常消耗CPU资源的，这一点在前面的文章已经谈到了，该问题解决办法有两个：加入线程休眠，设置固定阈值。就可控程度而言，很明显最好采用设置固定阈值的方式来避免一直空转而导致CPU飙高**

**  ** **设置固定阈值就是说将超过该次数仍未获取到CAS轻量级锁的线程直接升级为重量级锁，从用户态切换到内核态，并将该线程直接阻塞在内核态，同时存放到内核态的锁池中(C++ Monitor对象成员EntrySet)，直到获取到重量级锁的线程释放之后再唤醒锁池中的阻塞线程重新开始竞争轻量级锁，超出阈值再升级为重量级锁，以此类推。**

**重量级锁底层基于C++ Monitor的monitorenter/monitorexit指令实现，同时依赖于操作系统的互斥锁MuteX Lock实现，由操作系统负责进行用户态和内核态的切换，导致执行效率大打折扣，源码可见HotSpot 64bit ObjectMonitor::enter函数**

### 5 JDK15为什么废弃偏向锁 ###

1.  **偏向锁导致synchronization子系统的代码复杂度过高，并且影响到了其他子系统，导致难以维护、升级**
2.  **在现在的jdk中，偏向锁带来的加锁时性能提升从整体上看并没有带来过多收益(撤销锁的成本过高，需要等待全局安全点，再暂停获取到偏向锁的线程做锁撤销)**
3.  **维持偏向锁的机会成本(opportunity cost)过高，所以不如废弃**

官方说明中有这么一段话: since the introduction of biased locking into HotSpot also change the amount of uncontended operations needed for that relation to remain true.，原子指令成本变化(我理解是降低)，导致自旋锁需要的原子指令次数变少(或者cas操作变少 个人理解)，所以自旋锁成本下降，故偏向锁的带来的优势就更小了。

### 6 锁粗化和锁消除 ###

**6.1** **锁粗化**

通常情况下，为了保证多线程间的有效并发，会要求每个线程持有锁的时间尽可能短，但是某些情况下，一个程序对同一个锁不间断、高频地请求、同步与释放，会消耗掉一定的系统资源，因为锁的请求、同步与释放本身会带来性能损耗，这样高频的锁请求就反而不利于系统性能的优化了，虽然单次同步操作的时间可能很短。

**锁粗化就是指任何事情都有个度，有些情况下我们反而希望把很多次锁的请求合并成一个请求，以降低短时间内大量锁请求、同步、释放带来的性能损耗。**

**6.2** **锁消除**

**锁消除是发生在编译器级别的一种锁优化方式，是一种逻辑概念。**

有时候我们写的代码完全不需要加锁，却执行了加锁操作。

比如，StringBuffer类的append操作：

<table> 
 <tbody> 
  <tr> 
   <td style="border-color:#000000;vertical-align:top;width:426.1pt;"> <pre style="margin-left:.0001pt;"><code>public static void main(String[] args) {

&nbsp;&nbsp;&nbsp; long start = System.currentTimeMillis();

&nbsp;&nbsp;&nbsp; int size = 10000;

&nbsp;&nbsp;&nbsp; for (int i = 0; i &lt; size; i++) {

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; createStringBuffer("supertian", "001001");

&nbsp;&nbsp;&nbsp; }

&nbsp;&nbsp;&nbsp; long timeCost = System.currentTimeMillis() - start;

&nbsp;&nbsp;&nbsp; System.out.println("createStringBuffer:" + timeCost + " ms");

}

public static String createStringBuffer(String str1, String str2) {

&nbsp;&nbsp;&nbsp; StringBuffer sBuf = new StringBuffer();

&nbsp;&nbsp;&nbsp; sBuf.append(str1);// append方法是同步操作

&nbsp;&nbsp;&nbsp; sBuf.append(str2);

&nbsp;&nbsp;&nbsp; return sBuf.toString();

}</code></pre> <p style="margin-left:0;text-align:justify;">&nbsp;</p> </td> 
  </tr> 
 </tbody> 
</table>

**代码中****createStringBuffer****方法中的局部对象sBuf，就只在该方法内的作用域有效，不同线程同时调用createStringBuffer()方法时，都会创建不同的sBuf对象，因此此时的append操作若是使用同步操作，就是白白浪费的系统资源。所以在底层实现里面，如果多次调用同一个锁对象的synchronized同步方法，那么实际上只会获取和释放锁各一次，不会每次调用同步方法都重复去获取和释放锁，从逻辑层面上理解，这里发生了“锁消除”**

## ##

### 7 synchronized源码分析总结 ###

1.  ** CPU****调度算法**

**先来先服务、最短作业法、优先级调度算法**

1.  ** CPU****上下文切换的原因和如何避免**

**自发性上下文切换：显示调用wait()/notify()阻塞和唤醒线程**

**非自发性上下文切换：CPU时间片分配不足**

**避免CPU上下文切换的方法：使用无锁编程、使用CAS轻量级锁、使用最少线程、协程。**

1.  ** CAS****原理和优缺点**

**CAS(V,E,N)** **当且仅当旧的预期值E==实际值V时，才会将实际值V修改为N**

**CAS****是实现轻量级锁的重要实现手段，需要结合JUC并发包中的原子类实现**

**优点：运行在用户态，不需要切换到内核态，执行效率高**

**缺点：**

**ABA** **问题：使用版本号+V==E联合条件判断**

**CPU****占用率高，CPU飙高：线程休眠，设置重试次数阈值**

**只适用于单个共享变量：只能使用一个全局共享的原子类变量来实现CAS**

**Synchronized****锁升级过程和原理分析**

**Synchronized****锁升级过程主要包括四个环节：无锁 -> 偏向锁 -> 轻量级锁 ->重量级锁，现在来总体回顾下synchronized锁升级原理和流程：**

1.  **首先，当前线程在执行synchronized同步代码快之前，默认是无锁状态(Object Monitor对象头Mark World锁状态标识001)**
2.  **当线程开始执行synchroized同步代码快时，会先去判断ObjectMonitor对象头中的Mark World锁状态标识是否是偏向锁(101)，如果是偏向锁，则校验当前线程id和对象头Mark World中的owner是否匹配，如果匹配，则说明当前线程已经获取过偏向锁，那么就不会执行CAS操作来获取偏向锁，而是直接复用已经获取到的偏向锁**
3.  **线程id和对象头Mark World中的owner不匹配，说明此时已经有其他线程获取到了偏向锁，需要执行偏向锁撤销操作，如果当前线程创建的锁对象撤销次数超过20次，会批量重偏向，也就是将偏向锁的所有权交给撤销次数超过20次的当前线程；当撤销次数超过40次，那么会批量撤销偏向锁**
4.  **如果ObjectMonitor对象头Mark World中的标识位不是偏向锁，则执行CAS(001,101)，当前线程获取到了偏向锁，将偏向锁标志(101)和当前获取到偏向锁的线程id写入到对象头ObjectMonitor MarkWorld中**
5.  ** ****在执行CAS(001,101)获取偏向锁的时候，如果有多个线程同时来竞争，那么会直接进行偏向锁的撤销，撤销成功后所有线程开始竞争轻量级锁，对象头Mark World锁状态标识更新为轻量级状态(000)**
6.  **轻量级锁也是通过CAS实现的，保证同一时刻只有一个线程能够获取到CAS轻量级锁，其他没有获取到CAS轻量级锁的线程会在用户态不断进行循环重试，不会阻塞，直到超过一定重试次数之后仍未获取到CAS轻量级锁，此时就会将锁升级为重量级锁，获取到CAS轻量级锁的线程会将当前线程id写入到对象头Mark World中**
7.  **升级为重量级锁的线程会从用户态切换到内核态，并立刻阻塞在内核态，同时将线程存入C++ Monitor对象的EntrySet锁池中，等待其他获取到重量级锁的线程释放锁后，唤醒锁池中所有阻塞的线程重新开始竞争轻量级锁，超过重试次数再升级为重量级锁，以此类推。需要注意的是重量级锁效率非常低，因为需要操作系统频繁在用户态和内核态之间进行切换，同时依赖操作系统的互斥锁MuteX Lock，synchronized锁就是重量级锁，其底层是基于HotSpot C++指令monitorenter/monitorexit实现的**
8.  **Java****对象在内存中的分布**

**Java****对象在内存中的分布主要包括三部分：对象头、实例数据、对齐填充**

**这三部分根据HotSpot 版本不同，所占字节数在32位和64位略有差异，本文以主流的64Bit版本为例来说明Java对象在内存中的分布和资源占用情况**

1.  **对象头Object Header 主要存放两类数据：Mark World和KlassPointer**

**Mark World** **占用8Bytes**

**存放的是对象运行时的数据，主要包括：  
HashCode内存地址、GC分代年龄、锁状态标记(3位=1位标记是否偏向锁+2 位标记锁类型)、当前获取到锁的线程id(ownerId)、偏向锁id、偏向锁时间戳**

**具体存放内容位数分配：**

**Mark World 8Bytes = 64bit =**

**Unused 25bit + HashCode 31bit + Unused 1bit + GC Age 4bit +** **锁状态标记3bit**

**Klass Pointer** **占用4Bytes(压缩后，默认开启了压缩)/8Bytes(压缩前)**

**存放对象所属类型的元数据的指针，JVM通过Klass Pointer的值来唯一定位对象所属类型**

1.  **实例数据：存放对象属性数据所占的位数，参照前文讲到的Java基本类型所占位数和字节的映射表**

1.  **对齐填充：由于JVM预定义规则要求Java对象所占字节数必须是8的整数倍(对象头+实例数据%8==0)，对齐填充作为填充器填充不足的部分：比如对象头占12Bytes，实例数据占5Bytes，所以对齐填充的是7Bytes，此时12+5+7=24%8=0**

**附：**

**Java****对象头Mark World中的锁状态标识位**

**1****位标识是否偏向锁(1/0)+2位标识锁类型 = 共3位**

**常见锁类型和对应的锁状态标识位：**

**无锁 001**

**偏向锁 101**

**轻量级锁 000**

**重量级锁 010**

**GC****标记 011**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwMDU2MzQx_size_16_color_FFFFFF_t_70]: /images/20221005/923e7c0665234e3c82aa36dc95472a9a.png
[20210619165306791.png]: /images/20221005/921c7ffe8a064693b66d6b388843d69c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwMDU2MzQx_size_16_color_FFFFFF_t_70 1]: /images/20221005/9b596b1e71d449b590f4b88c5a4a17cb.png