转载

JVM源码分析之synchronized实现

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 **指令。

JVM源码分析之synchronized实现

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

JVM源码分析之synchronized实现

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 函数:

JVM源码分析之synchronized实现

偏向锁的获取

偏向锁的获取由 BiasedLocking::revoke_and_rebias 方法实现,由于实现比较长,就不贴代码了,实现逻辑如下:

markOop mar

偏向锁的撤销

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

JVM源码分析之synchronized实现

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

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

轻量级锁

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

轻量级锁的获取

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

JVM源码分析之synchronized实现

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 完成。

JVM源码分析之synchronized实现

1、确保处于偏向锁状态时不会执行这段逻辑;

2、取出在获取轻量级锁时保存在BasicLock对象的mark数据dhw;

3、通过CAS尝试把dhw替换到当前的Mark Word,如果CAS成功,说明成功的释放了锁,否则执行步骤(4);

4、如果CAS失败,说明有其它线程在尝试获取该锁,这时需要将该锁升级为重量级锁,并释放;

重量级锁

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

锁膨胀过程

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

JVM源码分析之synchronized实现

膨胀过程的实现比较复杂,截图中只是一小部分逻辑,完整的方法可以查看 synchronized.cpp ,大概实现过程如下:

mark->has_monitor()
mark->monitor()

JVM源码分析之synchronized实现

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 方法中。

JVM源码分析之synchronized实现

1、通过CAS尝试把monitor的_owner字段设置为当前线程;

2、如果设置之前的_owner指向当前线程,说明当前线程再次进入monitor,即重入锁,执行_recursions ++ ,记录重入的次数;

3、如果之前的_owner指向的地址在当前线程中,这种描述有点拗口,换一种说法:之前_owner指向的BasicLock在当前线程栈上,说明当前线程是第一次进入该monitor,设置_recursions为1,_owner为当前线程,该线程成功获得锁并返回;

4、如果获取锁失败,则等待锁的释放;

monitor等待

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

JVM源码分析之synchronized实现

1、当前线程被封装成ObjectWaiter对象node,状态设置成ObjectWaiter::TS_CXQ;

2、在for循环中,通过CAS把node节点push到_cxq列表中,同一时刻可能有多个线程把自己的node节点push到_cxq列表中;

3、node节点push到_cxq列表之后,通过自旋尝试获取锁,如果还是没有获取到锁,则通过park将当前线程挂起,等待被唤醒,实现如下:

JVM源码分析之synchronized实现 4、当该线程被唤醒时,会从挂起的点继续执行,通过 ObjectMonitor::TryLock 尝试获取锁,TryLock方法实现如下:

JVM源码分析之synchronized实现

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

monitor释放

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

JVM源码分析之synchronized实现

1、如果是重量级锁的释放,monitor中的_owner指向当前线程,即THREAD == _owner;

2、根据不同的策略(由QMode指定),从cxq或EntryList中获取头节点,通过 ObjectMonitor::ExitEpilog 方法唤醒该节点封装的线程,唤醒操作最终由unpark完成,实现如下:

JVM源码分析之synchronized实现 3、被唤醒的线程,继续执行monitor的竞争;

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

365天干货不断微信搜索「猿灯塔」第一时间阅读,回复【资料】【面试】【简历】有我准备的一线大厂面试资料和简历模板

原文  https://segmentfault.com/a/1190000022696968
正文到此结束
Loading...