jvm细节探索之synchronized及实现问题分析

 更新时间:2017年11月28日 11:01:01   作者:JAVA Miner  
这篇文章主要介绍了jvm细节探索之synchronized及实现问题分析,涉及synchronized的字节码表示,JVM中锁的优化,对象头的介绍等相关内容,具有一定借鉴价值,需要的朋友可以参考下。

在C程序代码中我们可以利用操作系统提供的互斥锁来实现同步块的互斥访问及线程的阻塞及唤醒等工作。然而在Java中除了提供LockAPI外还在语法层面上提供了synchronized关键字来实现互斥同步原语。那么到底在JVM内部是怎么实现synchronized关键子的呢?

一、synchronized的字节码表示:

在java语言中存在两种内建的synchronized语法:1、synchronized语句;2、synchronized方法。对于synchronized语句当Java源代码被javac编译成bytecode的时候,会在同步块的入口位置和退出位置分别插入monitorenter和monitorexit字节码指令。而synchronized方法则会被翻译成普通的方法调用和返回指令如:invokevirtual、areturn指令,在VM字节码层面并没有任何特别的指令来实现被synchronized修饰的方法,而是在Class文件的方法表中将该方法的access_flags字段中的synchronized标志位置1,表示该方法是同步方法并使用调用该方法的对象或该方法所属的Class在JVM的内部对象表示Klass做为锁对象。

二、JVM中锁的优化:

简单来说在JVM中monitorenter和monitorexit字节码依赖于底层的操作系统的MutexLock来实现的,但是由于使用MutexLock需要将当前线程挂起并从用户态切换到内核态来执行,这种切换的代价是非常昂贵的;然而在现实中的大部分情况下,同步方法是运行在单线程环境(无锁竞争环境)如果每次都调用MutexLock那么将严重的影响程序的性能。不过在jdk1.6中对锁的实现引入了大量的优化,如锁粗化(LockCoarsening)、锁消除(LockElimination)、轻量级锁(LightweightLocking)、偏向锁(BiasedLocking)、适应性自旋(AdaptiveSpinning)等技术来减少锁操作的开销。

锁粗化(LockCoarsening):也就是减少不必要的紧连在一起的unlock,lock操作,将多个连续的锁扩展成一个范围更大的锁。

锁消除(LockElimination):通过运行时JIT编译器的逃逸分析来消除一些没有在当前同步块以外被其他线程共享的数据的锁保护,通过逃逸分析也可以在线程本地Stack上进行对象空间的分配(同时还可以减少Heap上的垃圾收集开销)。

轻量级锁(LightweightLocking):这种锁实现的背后基于这样一种假设,即在真实的情况下我们程序中的大部分同步代码一般都处于无锁竞争状态(即单线程执行环境),在无锁竞争的情况下完全可以避免调用操作系统层面的重量级互斥锁,取而代之的是在monitorenter和monitorexit中只需要依靠一条CAS原子指令就可以完成锁的获取及释放。当存在锁竞争的情况下,执行CAS指令失败的线程将调用操作系统互斥锁进入到阻塞状态,当锁被释放的时候被唤醒(具体处理步骤下面详细讨论)。

偏向锁(BiasedLocking):是为了在无锁竞争的情况下避免在锁获取过程中执行不必要的CAS原子指令,因为CAS原子指令虽然相对于重量级锁来说开销比较小但还是存在非常可观的本地延迟(可参考这篇文章)。

适应性自旋(AdaptiveSpinning):当线程在获取轻量级锁的过程中执行CAS操作失败时,在进入与monitor相关联的操作系统重量级锁(mutexsemaphore)前会进入忙等待(Spinning)然后再次尝试,当尝试一定的次数后如果仍然没有成功则调用与该monitor关联的semaphore(即互斥锁)进入到阻塞状态。

三、对象头(ObjectHeader):

在JVM中创建对象时会在对象前面加上两个字大小的对象头,在32位机器上一个字为32bit,根据不同的状态位MarkWorld中存放不同的内容,如上图所示在轻量级锁中,MarkWord被分成两部分,刚开始时LockWord为被设置为HashCode、最低三位表示LockWord所处的状态,初始状态为001表示无锁状态。Klassptr指向Class字节码在虚拟机内部的对象表示的地址。Fields表示连续的对象实例字段。

四、MonitorRecord:

MonitorRecord是线程私有的数据结构,每一个线程都有一个可用monitorrecord列表,同时还有一个全局的可用列表;那么这些monitorrecord有什么用呢?每一个被锁住的对象都会和一个monitorrecord关联(对象头中的LockWord指向monitorrecord的起始地址,由于这个地址是8byte对齐的所以LockWord的最低三位可以用来作为状态位),同时monitorrecord中有一个Owner字段存放拥有该锁的线程的唯一标识,表示该锁被这个线程占用。如下图所示为MonitorRecord的内部结构:

Owner:初始时为NULL表示当前没有任何线程拥有该monitor record,当线程成功拥有该锁后保存线程唯一标识,当锁被释放时又设置为NULL;

EntryQ:关联一个系统互斥锁(semaphore),阻塞所有试图锁住monitor record失败的线程。

RcThis:表示blocked或waiting在该monitor record上的所有线程的个数。

Nest:用来实现重入锁的计数。

HashCode:保存从对象头拷贝过来的HashCode值(可能还包含GC age)。

Candidate:用来避免不必要的阻塞或等待线程唤醒,因为每一次只有一个线程能够成功拥有锁,如果每次前一个释放锁的线程唤醒所有正在阻塞或等待的线程,会引起不必要的上下文切换(从阻塞到就绪然后因为竞争锁失败又被阻塞)从而导致性能严重下降。Candidate只有两种可能的值0表示没有需要唤醒的线程1表示要唤醒一个继任线程来竞争锁。

五、轻量级锁具体实现:

一个线程能够通过两种方式锁住一个对象:1、通过膨胀一个处于无锁状态(状态位001)的对象获得该对象的锁;2、对象已经处于膨胀状态(状态位00)但LockWord指向的monitor record的Owner字段为NULL,则可以直接通过CAS原子指令尝试将Owner设置为自己的标识来获得锁。

获取锁(monitorenter)的大概过程如下:

(1)当对象处于无锁状态时(RecordWord值为HashCode,状态位为001),线程首先从自己的可用moniter record列表中取得一个空闲的moniter record,初始Nest和Owner值分别被预先设置为1和该线程自己的标识,一旦monitor record准备好然后我们通过CAS原子指令安装该monitor record的起始地址到对象头的LockWord字段来膨胀(原文为inflate,我觉得之所以叫inflate主要是由于当对象被膨胀后扩展了对象的大小;为了空间效率,将monitor record结构从对象头中抽出去,当需要的时候才将该结构attach到对象上,但是和这篇Paper有点互相矛盾,两种实现方式稍微有点不同)该对象,如果存在其他线程竞争锁的情况而调用CAS失败,则只需要简单的回到monitorenter重新开始获取锁的过程即可。

(2)对象已经被膨胀同时Owner中保存的线程标识为获取锁的线程自己,这就是重入(reentrant)锁的情况,只需要简单的将Nest加1即可。不需要任何原子操作,效率非常高。

(3)对象已膨胀但Owner的值为NULL,当一个锁上存在阻塞或等待的线程同时锁的前一个拥有者刚释放锁时会出现这种状态,此时多个线程通过CAS原子指令在多线程竞争状态下试图将Owner设置为自己的标识来获得锁,竞争失败的线程在则会进入到第四种情况(4)的执行路径。

(4)对象处于膨胀状态同时Owner不为NULL(被锁住),在调用操作系统的重量级的互斥锁之前先自旋一定的次数,当达到一定的次数时如果仍然没有成功获得锁,则开始准备进入阻塞状态,首先将rfThis的值原子性的加1,由于在加1的过程中可能会被其他线程破坏Object和monitor record之间的关联,所以在原子性加1后需要再进行一次比较以确保LockWord的值没有被改变,当发现被改变后则要重新进行monitorenter过程。同时再一次观察Owner是否为NULL,如果是则调用CAS参与竞争锁,锁竞争失败则进入到阻塞状态。

释放锁(monitorexit)的大概过程如下:

(1)首先检查该对象是否处于膨胀状态并且该线程是这个锁的拥有者,如果发现不对则抛出异常;

(2)检查Nest字段是否大于1,如果大于1则简单的将Nest减1并继续拥有锁,如果等于1,则进入到第(3)步;

(3)检查rfThis是否大于0,设置Owner为NULL然后唤醒一个正在阻塞或等待的线程再一次试图获取锁,如果等于0则进入到第(4)步

(4)缩小(deflate)一个对象,通过将对象的LockWord置换回原来的HashCode值来解除和monitor record之间的关联来释放锁,同时将monitor record放回到线程是有的可用monitor record列表。

总结

参考:《深入理解Java虚拟机 JVM高级特性与最佳实践(周志明)

以上就是本文关于jvm细节探索之synchronized及实现问题分析的全部内容,希望对大家有所帮助。如有不足之处,欢迎留言指出。感谢朋友们对本站的支持!

相关文章

  • Java封装好的mail包发送电子邮件的类

    Java封装好的mail包发送电子邮件的类

    本文给大家分享了2个java封装好的mail包发送电子邮件的类,并附上使用方法,小伙伴们可以根据自己的需求自由选择。
    2016-01-01
  • Java的覆写操作实例分析

    Java的覆写操作实例分析

    这篇文章主要介绍了Java的覆写操作,结合实例形式分析了java属性覆写及super调用父类方法覆写相关操作技巧,需要的朋友可以参考下
    2019-10-10
  • Java读取resources目录下文件路径的九种代码示例教程

    Java读取resources目录下文件路径的九种代码示例教程

    在Java开发中经常需要读取项目中resources目录下的文件或获取资源路径,这篇文章主要给大家介绍了关于Java读取resources目录下文件路径的九种代码示例教程,文中通过代码介绍的非常详细,需要的朋友可以参考下
    2024-07-07
  • Java线程池实现带返回值的方式方法

    Java线程池实现带返回值的方式方法

    在Java中,线程池是一种重要的多线程处理方式,可以有效管理和重用线程,提高程序的性能和效率,有时候我们需要在多线程处理中获取线程的返回值,本文将介绍如何使用线程池实现带返回值的方式方法,需要的朋友可以参考下
    2024-09-09
  • SpringBoot使用Maven插件进行项目打包的方法

    SpringBoot使用Maven插件进行项目打包的方法

    这篇文章主要介绍了SpringBoot使用Maven插件进行项目打包的方法,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2020-11-11
  • 详解JAVA设计模式之模板模式

    详解JAVA设计模式之模板模式

    这篇文章主要介绍了详解JAVA设计模式之模板模式的的相关资料,文中讲解非常细致,代码帮助大家更好的理解和学习,感兴趣的朋友可以了解下
    2020-06-06
  • 谈谈Java中try-catch-finally中的return语句

    谈谈Java中try-catch-finally中的return语句

    我们知道return语句用在某一个方法中,一是用于返回函数的执行结果,二是用于返回值为void类型的函数中,仅仅是一个return语句(return ;),此时用于结束方法的执行,也即此return后的语句将不会被执行,当然,这种情况下return语句后不能再有其它的语句了
    2016-01-01
  • Java中两个字符串进行大小比较的方法

    Java中两个字符串进行大小比较的方法

    这篇文章主要介绍了Java中两个字符串进行大小比较,符串是否相等比较,只能使用equals()方法,不能使用“==”,本文通过示例代码给大家介绍的非常详细,需要的朋友可以参考下
    2022-12-12
  • java分页工具类的使用方法

    java分页工具类的使用方法

    这篇文章主要为大家详细介绍了java分页工具类的使用方法,稳定的分页效果,包括导航页码功能,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2018-03-03
  • Java中的Semaphore信号量详解

    Java中的Semaphore信号量详解

    这篇文章主要介绍了Java中的Semaphore信号量详解,Semaphore(信号量)是用来控制同时访问特定资源的线程数量,通过协调各个线程以保证合理地使用公共资源,需要的朋友可以参考下
    2023-12-12

最新评论