synchronized的底层实现原理

synchronized的底层实现原理

转载自https://baijiahao.baidu.com/s?id=1612142459503895416&wfr=spider&for=pc，记录下别人分析的结果。
synchronized锁的底层实现

MDove：我们都知道，对象被创建在堆中。并且对象在内存中的存储布局方式可以分为3块区域：对象头、实例数据、对齐填充。其中对象头，便是我们今天的主角。

关于实例数据、对齐填充的作用，各位小伙伴可以参考《深入理解Java虚拟机》。

MDove：对于对象头来说，主要是包括俩部分信息：

1、自身运行时的数据，比如：锁状态标志、线程持有的锁…等等。（此部分内容被称之为Mark Word）

今天我们只聊：指向重量级锁的指针

2、另一部分是类型指针：JVM通过这个指针来确定这个对象是哪个类的实例。

MDove：今天我们主要聊的是对象头，第一部分中重量级锁的内容。

MDove：先让我们从宏观的角度看一看synchronized锁的实现原理。

synchronized锁的宏观实现

MDove：synchronized的对象锁，其指针指向的是一个monitor对象（由C++实现）的起始地址。每个对象实例都会有一个 monitor。其中monitor可以与对象一起创建、销毁；亦或者当线程试图获取对象锁时自动生成。

monitor是由ObjectMonitor实现（ObjectMonitor.hpp文件，C++实现的），对于我们来说主要关注的是如下代码：

MDove：我们可以看到这里定义了_WaitSet 和 _EntryList俩个队列，其中_WaitSet 用来保存每个等待锁的线程对象。

小A：那_EntryList呢？

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

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

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

synchronized代码块的底层实现

MDove：咱们先写一个简单的demo，然后看一下它们的字节码：

MDove：根据虚拟机规范要求，在执行monitorenter指令时，首先要尝试获取对象锁，也就是上文我们提到了monitor对象。如果这个对象没有被锁定，或者当前线程已经拥有了这个对象的锁，那么就把锁的计数器（_count）加1。当然与之对应执行monitorexit指令时，锁的计数器（_count）也会减1。

MDove：如果当前线程获取锁失败，那么就会被阻塞住，进入_WaitSet 中，等待锁被释放为止。

小A：等等，我看到字节码中，有俩个monitorexit指令，这是为什么呢？

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

小A：我们刚才看的是同步代码块的原理，那么直接修饰在方法上呢？也是通过这个俩个指令吗？

MDove：你别说，还真不是：

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