美文网首页jvmsynchronized详解java
JVM源码分析之synchronized实现

JVM源码分析之synchronized实现

作者: 美团Java | 来源:发表于2016-11-27 15:35 被阅读13807次

    转载请注明原创出处,谢谢!
    简书占小狼
    http://www.jianshu.com/users/90ab66c248e6/latest_articles

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

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

    synchronized字节码实现

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


    synchronized关键字基于上述两个指令实现了锁的获取和释放过程,解释器执行monitorenter时会进入到InterpreterRuntime.cppInterpreterRuntime::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方法实现,由于实现比较长,就不贴代码了,实现逻辑如下:
    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方法实现:

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

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

    轻量级锁

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

    轻量级锁的获取

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

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


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

    重量级锁

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

    锁膨胀过程

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

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

    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关键字有更加深刻的理解。


    我是占小狼
    坐标魔都,白天是上班族,晚上是知识的分享者
    如果读完觉得有收获的话,欢迎点赞加关注


    我的微信公众号

    相关文章

      网友评论

      • e66f8718771e:请问ObjectMonitor::enter具体是在哪里调用的?
      • 水欣:如果两个线程轮流的执行,是不是也可以使用偏向锁?两个线程竞争锁,偏向锁升级为轻量级锁,在轻量级锁下,两个线程竞争,升级为重量级锁,咋感觉轻量级锁好鸡肋
        来搞事情:两个线程轮流执行就会使用轻量级锁了,如果两个线程竞争就是重量级锁了;偏向锁是偏向第一个线程,如果再来一个线程就不是偏向锁了。
      • 九州智库:轻量级锁如果有重入,则将其displaced置为空,这是为何?
      • masterFan:3、撤销偏向锁,恢复到无锁(标志位为 01)或轻量级锁(标志位为 00)的状态;
        什么情况会恢复到无锁 or 轻量级锁?
      • _六道木:你好,请问一下,在获取轻量级锁的时候,有monitor record这个东西吗,
        _六道木:@占小狼 我看您的上面写轻量级锁只是涉及了mark这个东西,monitor record这个是在上面描述的几步中的哪一步进行操作的(或者是源码里的哪个方法里)
        美团Java:@阿涛啊 轻量级锁也需要的
      • ffdc65a4af66:monitor record 具体是怎么获取的?
      • b8050916e6bd:想问下博主,QMode策略是什么
      • JAVA编程手记:看一篇我要附加看N篇:joy: :joy: :joy:
      • Selina_lin:怎么办,想献出膝盖。
        Selina_lin:@占小狼 哈哈。
        美团Java:@AndroidLin 膝盖怎么够
      • codingwolf:对了,最近我们滴滴顺风车在招android开发,有需要的可以找我内推哟,可以直接把简历发我邮箱673391138@qq.com,也可以加我微信详细了解滴滴顺风车codingwolf
      • 夜月行者:小狼哥,看您在评论中说重量级锁是依赖系统的Mutex Lock实现的,但是看您的代码中在重量级锁的竞争中没有看到相关的分析,麻烦能帮忙解释一下吗
        2fe51012339c:Parker的park unpark里
      • hongrm:狼哥,有一点我感觉很疑惑,在轻量级锁的释放过程中,锁不是被该线程占有吗?别的线程要CAS替换Mark Word 肯定是失败的,那在占有锁的线程中释放锁的CAS操作为什么还存在失败的情况呢?
        hongrm:是因为中间有别的线程修改了锁标志位的缘故吗?
      • 夜月行者:小狼哥,在您讲偏向锁的时候看到第5条说的意思是只要有第二个线程加入的话,即使第一个线程已经用不到该锁(因为不会主动释放),还是会升级为轻量级锁么,但是讲偏向锁的撤销的时候又提到有机会不升级,只是撤销,这样其他线程又有机会获取偏向锁了,这种对应的是什么情况呢,麻烦您了!
      • e380688e348b:你好,我想请教个问题,HotSpot会有自旋优化策略,我在在ObjectMonitor::EnterI中并没有发现控制自旋时间的代码,我想请问下是怎么控制自旋时间的,谢谢!
        美团Java:@狂奔的龟 等我看看
      • f76f9308d391:我有个问题。
        HotSpot的作者经过研究发现,大多数情况下,锁不仅不存在多线程竞争,而且总是由同一线程多次获得,为了让线程获得锁的代价更低而引入了偏向锁。
        1. 一个线程获取到锁,别的线程不就是处于竞争锁的状态吗,为什么文中说"大多数情况下,不存在多线程竞争"?
        2. “总是由同一线程多次获得”,线程执行完不就销毁吗,为什么还多次获得?
        f76f9308d391:@hyuanhy :smiley: 懂了懂了,thx
        e66f8718771e:1. 一个线程获取到锁并不意味着别的线程处于竞争锁的状态,只要它们轮流进入critical section没有重叠互不干扰,那就不存在竞争,这在critical section比较短小的情况下是极可能的。
        2. “总是由同一线程获得”是指一个线程执行过程中先后多次访问了被synchronized保护的代码段,这时偏向锁就发挥作用了,因为同一线程进入自己把持的偏向锁不需要CAS,而且出来时也并不主动释放锁,所以开销很小。
        美团Java:@淡淡的时候 让我想想,好久都忘记了:joy:
      • 布吉刀:如果是重量级锁的释放,monitor中的_owner指向当前线程,即THREAD == _owner;
      • 布吉刀:通过CAS原子指令设置mark中JavaThread为当前线程ID
      • lemon_jason:你好,对于synchronized方法,编译后的字节码是这样的:
        public synchronized void f();
        Code:
        0: return

        请问这个怎么理解?为什么没有Monitorenter 与 Monitorexit指令?
        e66f8718771e:f 函数是空的吗?如果 f 什么也没做,是不是编译器进行了锁消除的优化
        lemon_jason:@占小狼 能否具体说明一下?
        美团Java:@lemon_jason synchronized方法和synchronized代码块的jvm实现逻辑不一样
      • Terminalist:小狼哥,文中可以指示下在hotspot的具体实现synchronized类和方法,方便我们自主学习:smile:
      • 吴敏_50f4:Hi,我对monitor对象的归属不太理解,以下两句都出自您文章:
        1.重量级锁通过对象内部的监视器(monitor)实现
        2.monitor是线程私有的数据结构,每一个线程都有一个可用monitor列表

        现有对象A,当该对象 被线程B 持有锁时。monitor对象是, 属于对象A,还是线程B?还是其他什么关系?
        Mars_M:monitor就是虚拟机的同步指令,所以不存在monitor对象属于对象A的说法,这两个对象是同一个对象,都是在java堆中。
        当线程B尝试进入同步块就会把对象A的对象头复制一份到线程B的虚拟机栈中的锁记录空间(monitor列表),如果线程B成功持有锁,对象A的对象头除了修改锁状态外,还有一个指针指向线程B虚拟机栈monitor列表的对象A对象头副本。
        这里还有一个容易混淆的地方,如果是重量级锁,其线程互斥是依赖于操作系统的Monitor,也就是管程。这个monitor跟虚拟机指令monitor就是两回事了。
      • 37d8ae4e1fd9:还有个问题,无竞争是偏向锁,有点竞争就升级轻量锁,偏向锁和轻量锁都是有竞争升级到重量锁,请问什么情况下能持续在轻量锁啊?我就想到是a,b两个线城的时候,a持有锁,b可能cas试几次,拿到就拿到了,超过次数就升级到重量锁。如果有c线程,就直接升级到重量锁。
        37d8ae4e1fd9: @占小狼 谢谢
        美团Java:@有点无聊 只要ab两个线程同时进入临界区,只有一个可以获取锁,这个时候就会膨胀成重量级锁
      • 37d8ae4e1fd9:两篇文章都看了,请教个问题,synchronized修饰代码块是monitorEnter monitorExit,修饰方法是其它实现吗?

        美团Java:@有点无聊 是相同的实现,只是所对象不一样
      • 37d8ae4e1fd9:👍 赞
      • 12346hys:支持
      • gowk:好帅的代码!
        美团Java:@gowk 哈哈哈

      本文标题:JVM源码分析之synchronized实现

      本文链接:https://www.haomeiwen.com/subject/pkwmpttx.html