java并发系列-monitor机制实现
2021-02-16 15:17
标签：turn may 自己 背景 waiting 轻量级 source 常量 mic 在jdk1.6以前synchronized的java内置锁不存在 偏向锁->轻量级锁->重量级锁 的锁膨胀机制，锁膨胀机制是1.6之后为了优化java线程同步性能而实现的。而1.6之前都是基于monitor机制的重量级锁。因为java内部对锁实现的封装，就算现在我们也只需要了解重量级锁就可以了。深入了解monitor机制对学习线程同步非常重要。 目录 monitor直译过来是监视器的意思，专业一点叫管程。monitor是属于编程语言级别的，它的出现是为了解决操作系统级别关于线程同步原语的使用复杂性，类似于语法糖，对复杂操作进行封装。而java则基于monitor机制实现了它自己的线程同步机制，就是synchronized内置锁。 monitor的作用就是限制同一时刻，只有一个线程能进入monitor框定的临界区，达到线程互斥，保护临界区中临界资源的安全，这称为线程同步使得程序线程安全。同时作为同步工具，它也提供了管理进程，线程状态的机制，比如monitor能管理因为线程竞争未能第一时间进入临界区的其他线程，并提供适时唤醒的功能。 3.1 monitor对象 monitor对象是monitor机制的核心，它本质上是jvm用c语言定义的一个数据类型。对应的数据结构保存了线程同步所需的信息，比如保存了被阻塞的线程的列表，还维护了一个基于mutex的锁，monitor的线程互斥就是通过mutex互斥锁实现的。 3.2 临界区 临界区是被synchronized包裹的代码块，可能是个代码块，也可能是个方法。 3.3 条件变量 条件变量和下方wait signal方法的使用有密切关系 。在获取锁进入临界区之后，如果发现条件变量不满足使用wait方法使线程阻塞，条件变量满足后signal唤醒被阻塞线程。 tips：当线程被signal唤醒之后，不是从wait那继续执行的，而是重新while循环一次判断条件是否成立。参考 3.4 定义在monitor对象上的wait() signal() signalAll()操作 4.1 首先先看一下synchronized同步代码块和同步方法编译后的字节码指令文件分别是什么样子 源代码如下 接着我们用javap查看 从上面可以看出，同步方法jvm是使用ACC_SYNCHRONIZED方法访问标识符实现同步，同步代码块jvm是使用monitorenter和monitorexit指令包裹临界区实现同步。 4.2 线程执行到同步方法处和同步代码块monitorenter和monitorexit指令分别发生了什么 这里需要看jvm的官方文档，下面三段话要好好读一读，monitor的运行逻辑都包含在里面。 同步方法 文档 同步代码块指令 文档 monitorenter monitorexit 对比官方文档描述的同步方法和同步代码块指令，其实功能类似。总结如下 1.同步方法和同步代码块都是通过monitor锁实现的。 2.两者的区别：同步方式是通过方法中的access_flags中设置ACC_SYNCHRONIZED标志来实现；同步代码块是通过monitorenter和monitorexit指令来实现 3.每个java对象都会与一个monitor相关联，可以由线程获取和释放。 4.如果线程没有获取到monitor会被阻塞。 5.monitor通过维护一个计数器来记录锁的获取，重入，释放情况。 由此可知当线程执行到同步方法发现此方法有ACC_SYNCHRONIZED标志或者执行到monitorenter指令时，会去尝试获取monitor锁。 那么就会有个疑问，既然线程需要获取monitor锁，那么什么是monitor锁，并且怎么才算获取monitor锁。 4.3 寻找monitor锁 这里先不甩结论，接下来我们一步一步搜寻monitor锁。 之前使用synchronized的时候知道，java中的每个对象都可以作为锁。 上面的官方文档也说了每个对象都与一个监视器关联。有理由猜测，任意的java对象在实例化的时候都同时生成了一个monitor锁与之一一对应。那么进一步猜测,通过java对象可以获取到和它对应的监视器。 这时候涉及到对象头的知识点。 4.3.1 对象头 对象头知识参考 每个java对象在内存中由对象头，实例数据和对齐填充三块区域组成。其中对象头存储了一些增强对象功能的信息，对象头中的Mark word 记录了锁的相关信息。如果此刻该对象锁升级为重量级锁，那么其中在对象头中存储了指向基于monitor锁的指针ptr_to_heavyweight_monitor。这个指针指向的就是我们苦苦寻找的锁。 既然监视器是指针指向的内存区域，那么这块内存区域肯定有自己的数据结构，而这个数据结构保存着线程同步的所有信息。 4.3.2 揭开monitor锁神秘面纱 详情参考 monitor的定义和初始化是有c语言编写的。 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/095e60e7fc8c/src/share/vm/runtime/objectMonitor.hpp 最重要的就是这两个c语言定义的类，objectMonitor就是对象头中指向的monitor重量级锁，objectWaiter是对等待线程的封装，可以用双向链表保存起来。 下面解释objectMonitor中属性的含义 定义： 说明: _header是一个markOop类型，markOop就是对象头中的Mark Word 定义： 说明：等待线程数 定义： 说明：锁重入次数 定义： 说明：监视器锁寄生的对象。锁不是平白出现的，而是寄托存储于对象中 定义： 说明： 指向获得ObjectMonitor对象的线程或基础锁 定义： 说明：处于wait状态的线程，被加入到这个linkedList 定义： 说明：protects Wait Queue - simple spinlock ，保护WaitSet的一个自旋锁(monitor大锁里面的一个小锁，这个小锁用来保护_WaitSet更改) 定义： 说明：未知 参考：https://www.jianshu.com/p/09de11d71ef8 定义： 说明：当锁被前一个线程释放，会指定一个假定继承者线程，但是它不一定最终获得锁。参考：https://www.jianshu.com/p/09de11d71ef8 定义： 说明：ContentionList 参考：https://www.jianshu.com/p/09de11d71ef8 定义： 说明：未知 定义： 说明：未获取锁被阻塞或者被wait的线程重新进入被放入entryList中 定义： 说明：未知 可能是获取锁的成功率 定义： 说明：未知 定义： 说明：当前owner是thread还是BasicLock 定义： 说明：当前owner的线程id 其实上面的属性中我们真正需要了解的就几个。下面大概描述一下。 4.3.3 线程的千里追踪 参考 _count++ 大概流程就是这样的，但是其中还有很多没有在这篇博客中提及的知识点就不深入了。 java并发系列-monitor机制实现 标签：turn may 自己 背景 waiting 轻量级 source 常量 mic 原文地址：https://www.cnblogs.com/qingshan-tang/p/12698705.html 背景
正文
什么是monitor 参考
monitor的作用
monitor的组成
java中monitor的实现
public class SynchronizedTest {
public synchronized void test1(){
}
public void test2(){
synchronized (this){
}
}
}
2.11.10. Synchronization
The Java Virtual Machine supports synchronization of both methods and sequences of instructions within a method by a single synchronization construct: the monitor.
Method-level synchronization is performed implicitly, as part of method invocation and return (§2.11.8). A synchronized method is distinguished in the run-time constant pool‘s method_info structure (§4.6) by the ACC_SYNCHRONIZED flag, which is checked by the method invocation instructions. When invoking a method for which ACC_SYNCHRONIZED is set, the executing thread enters a monitor, invokes the method itself, and exits the monitor whether the method invocation completes normally or abruptly. During the time the executing thread owns the monitor, no other thread may enter it. If an exception is thrown during invocation of the synchronized method and the synchronized method does not handle the exception, the monitor for the method is automatically exited before the exception is rethrown out of the synchronized method.
Synchronization of sequences of instructions is typically used to encode the synchronized block of the Java programming language. The Java Virtual Machine supplies the monitorenter and monitorexit instructions to support such language constructs. Proper implementation of synchronized blocks requires cooperation from a compiler targeting the Java Virtual Machine (§3.14).
Structured locking is the situation when, during a method invocation, every exit on a given monitor matches a preceding entry on that monitor. Since there is no assurance that all code submitted to the Java Virtual Machine will perform structured locking, implementations of the Java Virtual Machine are permitted but not required to enforce both of the following two rules guaranteeing structured locking. Let T be a thread and M be a monitor. Then:
The number of monitor entries performed by T on M during a method invocation must equal the number of monitor exits performed by T on M during the method invocation whether the method invocation completes normally or abruptly.
At no point during a method invocation may the number of monitor exits performed by T on M since the method invocation exceed the number of monitor entries performed by T on M since the method invocation.
Note that the monitor entry and exit automatically performed by the Java Virtual Machine when invoking a synchronized method are considered to occur during the calling method‘s invocation.
2.11.10。同步化
Java虚拟机通过单个同步结构（监视器）支持方法和方法中指令序列的同步。
作为方法调用和返回的一部分，方法级同步是隐式执行的（第2.11.8节）。甲synchronized方法是在运行时间常量池中的区分method_info结构（§4.6由）ACC_SYNCHRONIZED标志，这是由方法调用指令进行检查。调用方法时ACC_SYNCHRONIZED设置为1时，无论方法调用是正常完成还是突然完成，执行线程都将进入监视器，调用方法本身并退出监视器。在执行线程拥有监视器的时间内，没有其他线程可以进入它。如果在调用synchronized方法期间引发了异常并且该synchronized方法不处理该异常，则在将该异常重新抛出该方法之前，该方法的监视器将自动退出synchronized。
指令序列的同步通常用于对synchronizedJava编程语言的块进行编码 。Java虚拟机提供了 monitorenter和monitorexit指令来支持这种语言构造。正确实现synchronized块需要目标Java虚拟机（第3.14节）的编译器的配合。
当方法调用期间，给定监视器上的每个出口与该监视器上的先前条目匹配时，就是结构锁定。由于不能保证提交给Java虚拟机的所有代码都将执行结构化锁定，因此允许但不要求强制执行以下两个保证结构化锁定的规则的Java虚拟机实现。设 T为线程， M为监视器。然后：
进行监控条目的数量由?上中号的方法调用期间必须等于由执行监控退出的数目?上中号 是否该方法调用完成正常或突然的方法调用期间。
在一个方法调用期间没有点可以通过执行监控退出的数目? 上中号，因为该方法的调用超过执行监视器条目的数量? 上中号，因为该方法调用。
请注意，在调用synchronized方法时，Java虚拟机在调用方法时自动执行的监视器进入和退出 被视为发生。
The objectref must be of type reference.
Each object is associated with a monitor. A monitor is locked if and only if it has an owner. The thread that executes monitorenter attempts to gain ownership of the monitor associated with objectref, as follows:
If the entry count of the monitor associated with objectref is zero, the thread enters the monitor and sets its entry count to one. The thread is then the owner of the monitor.
If the thread already owns the monitor associated with objectref, it reenters the monitor, incrementing its entry count.
If another thread already owns the monitor associated with objectref, the thread blocks until the monitor‘s entry count is zero, then tries again to gain ownership.
该objectref的类型必须是reference。
每个对象都与一个监视器关联。监视器只有在拥有所有者的情况下才被锁定。执行monitorenter的线程 尝试获得与objectref关联的监视器的所有权，如下所示：
如果与objectref关联的监视器的条目计数 为零，则线程进入监视器，并将其条目计数设置为1。然后，该线程是监视器的所有者。
如果线程已经拥有与objectref关联的监视器 ，则它将重新进入监视器，从而增加其条目计数。
如果另一个线程已经拥有与objectref相关联的监视器 ，则该线程将阻塞，直到该监视器的条目计数为零为止，然后再次尝试获取所有权。
The thread decrements the entry count of the monitor associated with objectref. If as a result the value of the entry count is zero, the thread exits the monitor and is no longer its owner. Other threads that are blocking to enter the monitor are allowed to attempt to do so.
该线程减少与objectref关联的监视器的条目计数。结果，如果条目计数的值为零，则线程退出监视器，并且不再是其所有者。其他被阻止进入监视器的线程也可以尝试这样做。
|-------------------------------------------------------|--------------------|
| Mark Word (32 bits) | State |
|-------------------------------------------------------|--------------------|
| identity_hashcode:25 | age:4 | biased_lock:1 | lock:2 | Normal |
|-------------------------------------------------------|--------------------|
| thread:23 | epoch:2 | age:4 | biased_lock:1 | lock:2 | Biased |
|-------------------------------------------------------|--------------------|
| ptr_to_lock_record:30 | lock:2 | Lightweight Locked |
|-------------------------------------------------------|--------------------|
| ptr_to_heavyweight_monitor:30 | lock:2 | Heavyweight Locked |
|-------------------------------------------------------|--------------------|
| | lock:2 | Marked for GC |
|-------------------------------------------------------|--------------------|
_header
volatile markOop _header; // displaced object header word - mark
_count
定义：
volatile intptr_t _count; // reference count to prevent reclaimation/deflation
// at stop-the-world time. See deflate_idle_monitors().
// _count is approximately |_WaitSet| + |_EntryList|
说明：抢占该锁的线程数 约等于 WaitSet.size + EntryList.size
_waiters
volatile intptr_t _waiters; // number of waiting threads
_recursions
volatile intptr_t _recursions; // recursion count, 0 for first entry
_object
void* volatile _object; // backward object pointer - strong root
_owner
void * volatile _owner; // pointer to owning thread OR BasicLock
_WaitSet
ObjectWaiter * volatile _WaitSet; // LL of threads wait()ing on the monitor
_WaitSetLock
volatile int _WaitSetLock; // protects Wait Queue - simple spinlock
_Responsible
Thread * volatile _Responsible
_succ
Thread * volatile _succ ; // Heir presumptive thread - used for futile wakeup throttling
_cxq
ObjectWaiter * volatile _cxq ; // LL of recently-arrived threads blocked on entry.
// The list is actually composed of WaitNodes, acting
// as proxies for Threads.
FreeNext
ObjectMonitor * FreeNext ; // Free list linkage
_EntryList
ObjectWaiter * volatile _EntryList ; // Threads blocked on entry or reentry.
_SpinFreq
volatile int _SpinFreq ; // Spin 1-out-of-N attempts: success rate
_SpinClock
volatile int _SpinClock ;
OwnerIsThread
int OwnerIsThread ; // _owner is (Thread *) vs SP/BasicLock
_previous_owner_tid
volatile jlong _previous_owner_tid; // thread id of the previous owner of the monitor
上一篇：【CompletableFuture】CompletableFuture测试runAsync()方法调用CompletableFuture.join()/get()方法阻塞主线程
下一篇：Weblogic启动时报错javax.persistence.OneToMany.orphanRemoval()Z
文章标题：java并发系列-monitor机制实现
文章链接：http://soscw.com/index.php/essay/56142.html