美文网首页
synchronized的底层实现原理

synchronized的底层实现原理

作者: 张鹏宇_42ef | 来源:发表于2020-06-17 22:16 被阅读0次

    1.对象被创建在堆中。并且对象在内存中的存储布局方式可以分为3块区域:对象头、实例数据、对齐填充。对象头在64位的虚拟机里边占用的是8个字节,96byte,对于对象头来说,主要是包括俩部分信息:
    1.自身运行时的数据,比如:锁状态标志、线程持有的锁…等等。(此部分内容被称之为Mark Word)

    image.png

    2.另一部分是类型指针( Class Metadata Address ):JVM通过这个指针来确定这个对象是哪个类的实例。

    synchronized锁的宏观实现

    synchronized的对象锁,其指针指向的是一个monitor对象(由C++实现)的起始地址。每个对象实例都会有一个 monitor。其中monitor可以与对象一起创建、销毁;亦或者当线程试图获取对象锁时自动生成。
    monitor是由ObjectMonitor实现(ObjectMonitor.hpp文件,C++实现的),对于我们来说主要关注的是如下代码


    image.png

    让我们先看一下_owner,它指向持有ObjectMonitor对象的线程。当多个线程同时访问一段同步代码时,会先存放到 _EntryList 集合中,接下来当线程获取到对象的monitor时,就会把_owner变量设置为当前线程。同时count变量+1。如果线程调用wait() 方法,就会释放当前持有的monitor,那么_owner变量就会被置为null,同时_count减1,并且该线程进入 WaitSet集合中,等待下一次被唤醒

    当然,若当前线程顺利执行完方法,也将释放monitor,重走一遍刚才的内容,也就是_owner变量就会被置为null,同时_count减1,并且该线程进入 WaitSet集合中,等待下一次被唤醒

    因为这个锁对象存放在对象本身,也就是为什么Java中任意对象可以作为锁的原因

    例子:


    image.png image.png

    根据虚拟机规范要求,在执行monitorenter指令时,首先要尝试获取对象锁,也就是上文我们提到了monitor对象。如果这个对象没有被锁定,或者当前线程已经拥有了这个对象的锁,那么就把锁的计数器(_count)加1。当然与之对应执行monitorexit指令时,锁的计数器(_count)也会减1。
    如果当前线程获取锁失败,那么就会被阻塞住,进入_WaitSet 中,等待锁被释放为止。

    !!!字节码中,有俩个monitorexit指令,这是为什么呢?
    是这样的,编译器需要确保方法中调用过的每条monitorenter指令都要执行对应的monitorexit 指令。为了保证在方法异常时,monitorenter和monitorexit指令也能正常配对执行,编译器会自动产生一个异常处理器,它的目的就是用来执行 异常的monitorexit指令。而字节码中多出的monitorexit指令,就是异常结束时,被执行用来释放monitor的。

    !!! 同步代码块和直接修饰在方法上有什么区别


    image.png

    可以看到:字节码中并没有monitorenter指令和monitorexit指令,取得代之的是ACC_SYNCHRONIZED标识,JVM通过ACC_SYNCHRONIZED标识,就可以知道这是一个需要同步的方法,进而执行上述同步的过程,也就是_count加1,这些过程。

    notify/notifyAll/wait等方法存在于顶级对象Object中的原因,在使用这3个方法时,必须处于synchronized代码块或者synchronized方法中,否则就会抛出IllegalMonitorStateException异常,
    我们知道monitor 存在于对象头的Mark Word 中(存储monitor引用指针),而synchronized关键字可以获取 monitor ,这也就是为什么notify/notifyAll和wait方法必须在synchronized代码块或者synchronized方法调用的原因

    相关文章

      网友评论

          本文标题:synchronized的底层实现原理

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