JVM源码分析之synchronized实现
“365篇 原创计划”第十二篇。
原创申明：本文由公众号【猿灯塔】原创，转载请说明出处标注
今天呢！灯塔君跟大家讲：
JVM源码分析之synchronized实现
java内部锁synchronized的出现，为多线程的并发执行提供了一个稳定的环境，有效的防止多个线程同时执行同一个逻辑，其实这篇文章应该写在 JVM源码分析之Object.wait/notify实现 机制之前，本文不会讲如何使用synchronized，以HotSpot1.7的虚拟机为例，对synchronized的实现进行深入分析。
synchronized的HotSpot实现依赖于对象头的Mark Word，关于Mark Word的描述可以参考这篇文章 JVM源码分析之Java对象头实现
synchronized字节码实现
通过javap命令生成的字节码中包含 ** monitorenter ** 和 ** monitorexit **指令。
synchronized关键字基于上述两个指令实现了锁的获取和释放过程，解释器执行monitorenter时会进入到 InterpreterRuntime.cpp 的 InterpreterRuntime::monitorenter 函数，具体实现如下：
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 函数：
偏向锁的获取
偏向锁的获取由 BiasedLocking::revoke_and_rebias 方法实现，由于实现比较长，就不贴代码了，实现逻辑如下：
markOop mar
偏向锁的撤销
只有当其它线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，偏向锁的撤销由 BiasedLocking::revoke_at_safepoint 方法实现：.
- 偏向锁的撤销动作必须等待全局安全点；
- 暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态；
- 撤销偏向锁，恢复到无锁（标志位为 01）或轻量级锁（标志位为 00）的状态；
偏向锁在Java 1.6之后是默认启用的，但在应用程序启动几秒钟之后才激活，可以使用 - `XX:BiasedLockingStartupDelay=0 参数关闭延迟，如果确定应用程序中所有锁通常情况下处于竞争状态，可以通过 XX:-UseBiasedLocking=false`参数关闭偏向锁。
轻量级锁
引入轻量级锁的目的：在多线程交替执行同步块的情况下，尽量避免重量级锁引起的性能消耗，但是如果多个线程在同一时刻进入临界区，会导致轻量级锁膨胀升级重量级锁，所以轻量级锁的出现并非是要替代重量级锁。
轻量级锁的获取
当关闭偏向锁功能，或多个线程竞争偏向锁导致偏向锁升级为轻量级锁，会尝试获取轻量级锁，其入口位于 ObjectSynchronizer::slow_enter
markOop mark = obj->mark() mark->is_neutral()
假设线程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 完成。
1、确保处于偏向锁状态时不会执行这段逻辑；
2、取出在获取轻量级锁时保存在BasicLock对象的mark数据dhw；
3、通过CAS尝试把dhw替换到当前的Mark Word，如果CAS成功，说明成功的释放了锁，否则执行步骤（4）；
4、如果CAS失败，说明有其它线程在尝试获取该锁，这时需要将该锁升级为重量级锁，并释放；
重量级锁
重量级锁通过对象内部的监视器（monitor）实现，其中monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的切换，切换成本非常高。
锁膨胀过程
锁的膨胀过程通过 ObjectSynchronizer::inflate 函数实现
膨胀过程的实现比较复杂，截图中只是一小部分逻辑，完整的方法可以查看 synchronized.cpp ，大概实现过程如下：
mark->has_monitor() mark->monitor()
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 方法中。
1、通过CAS尝试把monitor的_owner字段设置为当前线程；
2、如果设置之前的_owner指向当前线程，说明当前线程再次进入monitor，即重入锁，执行_recursions ++ ，记录重入的次数；
3、如果之前的_owner指向的地址在当前线程中，这种描述有点拗口，换一种说法：之前_owner指向的BasicLock在当前线程栈上，说明当前线程是第一次进入该monitor，设置_recursions为1，_owner为当前线程，该线程成功获得锁并返回；
4、如果获取锁失败，则等待锁的释放；
monitor等待
monitor竞争失败的线程，通过自旋执行 ObjectMonitor::EnterI 方法等待锁的释放，EnterI方法的部分逻辑实现如下：
1、当前线程被封装成ObjectWaiter对象node，状态设置成ObjectWaiter::TS_CXQ；
2、在for循环中，通过CAS把node节点push到_cxq列表中，同一时刻可能有多个线程把自己的node节点push到_cxq列表中；
3、node节点push到_cxq列表之后，通过自旋尝试获取锁，如果还是没有获取到锁，则通过park将当前线程挂起，等待被唤醒，实现如下：
4、当该线程被唤醒时，会从挂起的点继续执行，通过 ObjectMonitor::TryLock 尝试获取锁，TryLock方法实现如下：
其本质就是通过CAS设置monitor的_owner字段为当前线程，如果CAS成功，则表示该线程获取了锁，跳出自旋操作，执行同步代码，否则继续被挂起；
monitor释放
当某个持有锁的线程执行完同步代码块时，会进行锁的释放，给其它线程机会执行同步代码，在HotSpot中，通过退出monitor的方式实现锁的释放，并通知被阻塞的线程，具体实现位于 ObjectMonitor::exit 方法中。
1、如果是重量级锁的释放，monitor中的_owner指向当前线程，即THREAD == _owner；
2、根据不同的策略（由QMode指定），从cxq或EntryList中获取头节点，通过 ObjectMonitor::ExitEpilog 方法唤醒该节点封装的线程，唤醒操作最终由unpark完成，实现如下：
3、被唤醒的线程，继续执行monitor的竞争；
希望通过本文的分析可以让大家对synchronized关键字有更加深刻的理解。
365天干货不断微信搜索「猿灯塔」第一时间阅读，回复【资料】【面试】【简历】有我准备的一线大厂面试资料和简历模板
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
