JVM源码分析之synchronized实现

柔光的暖阳◎ 2021-06-10 20:38 455阅读 0赞

java内部锁synchronized的出现，为多线程的并发执行提供了一个稳定的环境，有效的防止多个线程同时执行同一个逻辑，其实这篇文章应该写在[深入分析Object.wait/notify实现机制][Object.wait_notify]之前，本文不会讲如何使用synchronized，以HotSpot1.7的虚拟机为例，对synchronized的实现进行深入分析。

synchronized的HotSpot实现依赖于对象头的Mark Word，关于Mark Word的描述可以参考这篇文章[《java对象头的HotSpot实现分析》][java_HotSpot]

### synchronized字节码实现 ###

![format_png][]

通过javap命令生成的字节码中包含 \*\* monitorenter \*\* 和 \*\* monitorexit \*\*指令。

![format_png 1][]

synchronized关键字基于上述两个指令实现了锁的获取和释放过程，解释器执行monitorenter时会进入到`InterpreterRuntime.cpp`的`InterpreterRuntime::monitorenter`函数，具体实现如下：

![format_png 2][]

1、JavaThread thread指向java中的当前线程；  
2、BasicObjectLock类型的elem对象包含一个BasicLock类型\_lock对象和一个指向Object对象的指针\_obj;

class BasicObjectLock {
      BasicLock _lock; 
      // object holds the lock;
      oop  _obj;   
    }

3、BasicLock类型\_lock对象主要用来保存\_obj指向Object对象的对象头数据；

class BasicLock {
        volatile markOop _displaced_header;
    }

4、**UseBiasedLocking**标识虚拟机是否开启偏向锁功能，如果开启则执行fast\_enter逻辑，否则执行slow\_enter；

### 偏向锁 ###

引入偏向锁的目的：在没有多线程竞争的情况下，尽量减少不必要的轻量级锁执行路径，轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只依赖一次CAS原子指令置换ThreadID，不过一旦出现多个线程竞争时必须撤销偏向锁，所以撤销偏向锁消耗的性能必须小于之前节省下来的CAS原子操作的性能消耗，不然就得不偿失了。JDK 1.6中默认开启偏向锁，可以通过-XX:-UseBiasedLocking来禁用偏向锁。

在HotSpot中，偏向锁的入口位于synchronizer.cpp文件的`ObjectSynchronizer::fast_enter`函数：

![format_png 3][]

偏向锁的获取

偏向锁的获取由`BiasedLocking::revoke_and_rebias`方法实现，由于实现比较长，就不贴代码了，实现逻辑如下：  
1、通过`markOop mark = obj->mark()`获取对象的markOop数据mark，即对象头的Mark Word；  
2、判断mark是否为可偏向状态，即mark的偏向锁标志位为 **1**，锁标志位为 **01**；  
3、判断mark中JavaThread的状态：如果为空，则进入步骤（4）；如果指向当前线程，则执行同步代码块；如果指向其它线程，进入步骤（5）；  
4、通过CAS原子指令设置mark中JavaThread为当前线程ID，如果执行CAS成功，则执行同步代码块，否则进入步骤（5）；  
5、如果执行CAS失败，表示当前存在多个线程竞争锁，当达到全局安全点（safepoint），获得偏向锁的线程被挂起，撤销偏向锁，并升级为轻量级，升级完成后被阻塞在安全点的线程继续执行同步代码块；

偏向锁的撤销

只有当其它线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，偏向锁的撤销由`BiasedLocking::revoke_at_safepoint`方法实现：

![format_png 4][]

1、偏向锁的撤销动作必须等待全局安全点；  
2、暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态；  
3、撤销偏向锁，恢复到无锁（标志位为 **01**）或轻量级锁（标志位为 **00**）的状态；

偏向锁在Java 1.6之后是默认启用的，但在应用程序启动几秒钟之后才激活，可以使用`-XX:BiasedLockingStartupDelay=0`参数关闭延迟，如果确定应用程序中所有锁通常情况下处于竞争状态，可以通过`XX:-UseBiasedLocking=false`参数关闭偏向锁。

### 轻量级锁 ###

引入轻量级锁的目的：在多线程交替执行同步块的情况下，尽量避免重量级锁引起的性能消耗，但是如果多个线程在同一时刻进入临界区，会导致轻量级锁膨胀升级重量级锁，所以轻量级锁的出现并非是要替代重量级锁。

轻量级锁的获取

当关闭偏向锁功能，或多个线程竞争偏向锁导致偏向锁升级为轻量级锁，会尝试获取轻量级锁，其入口位于`ObjectSynchronizer::slow_enter`

![format_png 5][]

1、`markOop mark = obj->mark()`方法获取对象的markOop数据mark；  
2、`mark->is_neutral()`方法判断mark是否为无锁状态：mark的偏向锁标志位为 **0**，锁标志位为 **01**；  
3、如果mark处于无锁状态，则进入步骤（4），否则执行步骤（6）；  
4、把mark保存到BasicLock对象的\_displaced\_header字段；  
5、通过CAS尝试将Mark Word更新为指向BasicLock对象的指针，如果更新成功，表示竞争到锁，则执行同步代码，否则执行步骤（6）；  
6、如果当前mark处于加锁状态，且mark中的ptr指针指向当前线程的栈帧，则执行同步代码，否则说明有多个线程竞争轻量级锁，轻量级锁需要膨胀升级为重量级锁；

**假设线程A和B同时执行到临界区`if (mark->is_neutral())`**：  
1、线程AB都把Mark Word复制到各自的\_displaced\_header字段，该数据保存在线程的栈帧上，是线程私有的；  
2、`Atomic::cmpxchg_ptr`原子操作保证只有一个线程可以把指向栈帧的指针复制到Mark Word，假设此时线程A执行成功，并返回继续执行同步代码块；  
3、线程B执行失败，退出临界区，通过`ObjectSynchronizer::inflate`方法开始膨胀锁；

轻量级锁的释放

轻量级锁的释放通过`ObjectSynchronizer::fast_exit`完成。

![format_png 6][]

1、确保处于偏向锁状态时不会执行这段逻辑；  
2、取出在获取轻量级锁时保存在BasicLock对象的mark数据dhw；  
3、通过CAS尝试把dhw替换到当前的Mark Word，如果CAS成功，说明成功的释放了锁，否则执行步骤（4）；  
4、如果CAS失败，说明有其它线程在尝试获取该锁，这时需要将该锁升级为重量级锁，并释放；

### 重量级锁 ###

重量级锁通过对象内部的监视器（monitor）实现，其中monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的切换，切换成本非常高。

锁膨胀过程

锁的膨胀过程通过`ObjectSynchronizer::inflate`函数实现

![format_png 7][]

膨胀过程的实现比较复杂，截图中只是一小部分逻辑，完整的方法可以查看`synchronized.cpp`，大概实现过程如下：  
1、整个膨胀过程在自旋下完成；  
2、`mark->has_monitor()`方法判断当前是否为重量级锁，即Mark Word的锁标识位为 **10**，如果当前状态为重量级锁，执行步骤（3），否则执行步骤（4）；  
3、`mark->monitor()`方法获取指向ObjectMonitor的指针，并返回，说明膨胀过程已经完成；  
4、如果当前锁处于膨胀中，说明该锁正在被其它线程执行膨胀操作，则当前线程就进行自旋等待锁膨胀完成，这里需要注意一点，虽然是自旋操作，但不会一直占用cpu资源，每隔一段时间会通过os::NakedYield方法放弃cpu资源，或通过park方法挂起；如果其他线程完成锁的膨胀操作，则退出自旋并返回；  
5、如果当前是轻量级锁状态，即锁标识位为 **00**，膨胀过程如下：

![format_png 8][]

1、通过omAlloc方法，获取一个可用的ObjectMonitor monitor，并重置monitor数据；  
2、通过CAS尝试将Mark Word设置为markOopDesc:INFLATING，标识当前锁正在膨胀中，如果CAS失败，说明同一时刻其它线程已经将Mark Word设置为markOopDesc:INFLATING，当前线程进行自旋等待膨胀完成；  
3、如果CAS成功，设置monitor的各个字段：\_header、\_owner和\_object等，并返回；

monitor竞争

当锁膨胀完成并返回对应的monitor时，并不表示该线程竞争到了锁，真正的锁竞争发生在`ObjectMonitor::enter`方法中。

![format_png 9][]

1、通过CAS尝试把monitor的\_owner字段设置为当前线程；  
2、如果设置之前的\_owner指向当前线程，说明当前线程再次进入monitor，即重入锁，执行\_recursions ++ ，记录重入的次数；  
3、如果之前的\_owner指向的地址在当前线程中，这种描述有点拗口，换一种说法：之前\_owner指向的BasicLock在当前线程栈上，说明当前线程是第一次进入该monitor，设置\_recursions为1，\_owner为当前线程，该线程成功获得锁并返回；  
4、如果获取锁失败，则等待锁的释放；

monitor等待

monitor竞争失败的线程，通过自旋执行`ObjectMonitor::EnterI`方法等待锁的释放，EnterI方法的部分逻辑实现如下：

![format_png 10][]

1、当前线程被封装成ObjectWaiter对象node，状态设置成ObjectWaiter::TS\_CXQ；  
2、在for循环中，通过CAS把node节点push到\_cxq列表中，同一时刻可能有多个线程把自己的node节点push到\_cxq列表中；  
3、node节点push到\_cxq列表之后，通过自旋尝试获取锁，如果还是没有获取到锁，则通过park将当前线程挂起，等待被唤醒，实现如下：

![format_png 11][]

4、当该线程被唤醒时，会从挂起的点继续执行，通过`ObjectMonitor::TryLock`尝试获取锁，TryLock方法实现如下：

![format_png 12][]

其本质就是通过CAS设置monitor的\_owner字段为当前线程，如果CAS成功，则表示该线程获取了锁，跳出自旋操作，执行同步代码，否则继续被挂起；

monitor释放

当某个持有锁的线程执行完同步代码块时，会进行锁的释放，给其它线程机会执行同步代码，在HotSpot中，通过退出monitor的方式实现锁的释放，并通知被阻塞的线程，具体实现位于`ObjectMonitor::exit`方法中。

![format_png 13][]

1、如果是重量级锁的释放，monitor中的\_owner指向当前线程，即THREAD == \_owner；  
2、根据不同的策略（由QMode指定），从cxq或EntryList中获取头节点，通过`ObjectMonitor::ExitEpilog`方法唤醒该节点封装的线程，唤醒操作最终由unpark完成，实现如下：

![format_png 14][]

3、被唤醒的线程，继续执行monitor的竞争；

希望本文的分析可以让大家对synchronized关键字有更加深刻的理解。

[Object.wait_notify]: https://www.jianshu.com/p/f4454164c017
[java_HotSpot]: https://www.jianshu.com/p/9c19eb0ea4d8
[format_png]: /images/20210527/4e75f07995e5489ca9bb9d0e69ef7137.png
[format_png 1]: /images/20210527/f2e0b343949745f5a3f0413d08b9049b.png
[format_png 2]: /images/20210527/87c73273592547aa9a65180ff3087590.png
[format_png 3]: /images/20210527/73bddc84c31b4da8b44bcc292f0139a1.png
[format_png 4]: /images/20210527/6e5d6b79a0b74b60aed92ae8096c4352.png
[format_png 5]: /images/20210527/c6fbbbcd787d4d60b9dac2cf53e8de23.png
[format_png 6]: /images/20210527/779370e1f9b24bdf8e6b433355eb3592.png
[format_png 7]: /images/20210527/c4afc4c5393745cb93f41ffd72f84415.png
[format_png 8]: /images/20210527/1ba902793c4d40e58e42071a0d6bf514.png
[format_png 9]: /images/20210527/68d391186c9b40ec944728983f4604e1.png
[format_png 10]: /images/20210527/592df4b328ef469bb0af5c2fbdc7e138.png
[format_png 11]: /images/20210527/02fc5ae0700b4e31865d6ff352c5de83.png
[format_png 12]: /images/20210527/c1fded1657334f3a8e65cc779206447f.png
[format_png 13]: /images/20210527/d9f55cd64396487e9e46f132d2f4517f.png
[format_png 14]: /images/20210527/a2e0ab49367e42e084342d649c7b81cb.png