文章目录
上篇文章《【并发编程】 — 从字节码指令的角度去理解synchronized关键字的原理》从字节码指令的角度讲解了synchronized关键字的原理，从中可以知道其实synchronized关键字真正锁的是锁对象关联的monitor对象，那
- （1）这个monitor对象到底什么呢？
- （2）monitorentor、monitorexit这两个字节码指令和monitor之间到底是什么关系呢？
- （3）为什么很多资料上都说monitor是重量级锁呢？
本篇文章将来讲解一下这几个问题。
1 openjdk(hotspot)源码下载
源码地址：http://openjdk.java.net/ --> Mercurial --> jdk8 --> hotspot --> zip
当然如果下载不下来，也可以从我提供的源码里clone： https://github.com/nieandsun/concurrent-study.git
2 monitor对象简介
首先应该知道，monitor并不是我们java开发人员主动创建的一个对象。事实上可以这么理解：monitor并不是随着对象的创建而创建的，而是我们通过synchronized修饰符告诉JVM需要为我们的某个对象（锁对象）创建关联的monitor对象。
在HotSpot虚拟机中，monitor是由ObjectMonitor实现的。其源码是用C++写的，位于HotSpot虚拟机源码ObjectMonitor.hpp文件中(src/share/vm/runtime/objectMonitor.hpp)。ObjectMonitor主要数据结构如下：
// initialize the monitor, exception the semaphore, all other fields
// are simple integers or pointers
ObjectMonitor() {
_header = NULL;
_count = 0;
_waiters = 0,
_recursions = 0;//线程的重入次数
_object = NULL;//存储改monitor的对象
_owner = NULL;//拥有该monitor的线程
_WaitSet = NULL;//处于wait状态的线程，会被加入到_WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;//多线程竞争锁时的单向列表
FreeNext = NULL ;
_EntryList = NULL ; //处于等待锁block状态的线程，会被加入到该列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
_previous_owner_tid = 0;
}
对其中几个比较重要的变量进行解释如下：
- （1）
_owner：初始时为NULL。当有线程占有该monitor时，owner标记为该线程的唯一标识。当线程 释放monitor时，owner又恢复为NULL。owner是一个临界资源，JVM是通过CAS操作来保证其线程的安全。 - （2）
_cxq：竞争队列，所有请求锁的线程首先会被放在这个队列中（单向链接）。_cxq是一个临界资 源，JVM通过CAS原子指令来修改_cxq队列。修改前_cxq的旧值填入了node的next字段，_cxq指 向新值（新线程）。因此_cxq是一个后进先出的stack（栈）。 - （3）
_EntryList：_cxq队列中有资格成为候选资源的线程会被移动到该队列中。 - （4）
_WaitSet：因为调用wait方法而被阻塞的线程会被放在该队列中。
锁对象与monitor中的_owner、_WaitSet以及_EntryList之间的关系可以用下图进行表示：
3 monitorenter、monitorexit与monitor之间的关系
monitorenter 和 monitorexit 这两个字节码指令到底与monitor之间是什么样的关系呢？
其实并没有那么不可想象！！！ 以monitorenter字节码指令为例，当JVM当发现要运行此字节码指令时，就会调用C++的 InterpreterRuntime::monitorenter函数，该函数的位于HotSpot虚拟机源码InterpreterRuntime.cpp中（src/share/vm/interpreter/interpreterRuntime.cpp)，具体源码如下：
IRT_ENTRY_NO_ASYNC(void, InterpreterRuntime::monitorenter(JavaThread* thread, BasicObjectLock* elem))
#ifdef ASSERT
thread->last_frame().interpreter_frame_verify_monitor(elem);
#endif
if (PrintBiasedLockingStatistics) {
Atomic::inc(BiasedLocking::slow_path_entry_count_addr());
}
Handle h_obj(thread, elem->obj());
assert(Universe::heap()->is_in_reserved_or_null(h_obj()),
"must be NULL or an object");
if (UseBiasedLocking) {
// Retry fast entry if bias is revoked to avoid unnecessary inflation
ObjectSynchronizer::fast_enter(h_obj, elem->lock(), true, CHECK); //JDK1.6及之后对锁进行的优化
} else {
ObjectSynchronizer::slow_enter(h_obj, elem->lock(), CHECK); //重量级锁
}
assert(Universe::heap()->is_in_reserved_or_null(elem->obj()),
"must be NULL or an object");
对于重量级锁，monitorenter函数中会调用 ObjectSynchronizer::slow_enter方法
并最终调用 ObjectMonitor::enter方法（位于：src/share/vm/runtime/objectMonitor.cpp），源码如下：
void ATTR ObjectMonitor::enter(TRAPS) {
// The following code is ordered to check the most common cases first
// and to reduce RTS->RTO cache line upgrades on SPARC and IA32 processors.
Thread * const Self = THREAD ;
void * cur ;
// 通过CAS操作尝试把monitor的_owner字段设置为当前线程
cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ;
if (cur == NULL) {
// Either ASSERT _recursions == 0 or explicitly set _recursions = 0.
assert (_recursions == 0 , "invariant") ;
assert (_owner == Self, "invariant") ;
// CONSIDER: set or assert OwnerIsThread == 1
return ;
}
// 线程重入，recursions++
if (cur == Self) {
// TODO-FIXME: check for integer overflow! BUGID 6557169.
_recursions ++ ;
return ;
}
// 如果当前线程是第一次进入该monitor，设置_recursions为1，_owner为当前线程
if (Self->is_lock_owned ((address)cur)) {
assert (_recursions == 0, "internal state error");
_recursions = 1 ;
// Commute owner from a thread-specific on-stack BasicLockObject address to
// a full-fledged "Thread *".
_owner = Self ;
OwnerIsThread = 1 ;
return ;
}
//省略一些代码。。。。
// TODO-FIXME: change the following for(;;) loop to straight-line code.
for (;;) {
jt->set_suspend_equivalent();
// cleared by handle_special_suspend_equivalent_condition()
// or java_suspend_self()
// 如果获取锁失败，则等待锁的释放；
EnterI (THREAD) ;
if (!ExitSuspendEquivalent(jt)) break ;
//
// We have acquired the contended monitor, but while we were
// waiting another thread suspended us. We don't want to enter
// the monitor while suspended because that would surprise the
// thread that suspended us.
//
_recursions = 0 ;
_succ = NULL ;
exit (false, Self) ;
jt->java_suspend_self();
}
Self->set_current_pending_monitor(NULL);
}
这里暂时先不考虑JDK1.6及之后对synchronized关键字进行的优化。
以上代码的具体流程概括起来如下：
- （1） 通过CAS尝试把monitor的owner字段设置为当前线程。 ---- 调用了内核函数 Atomic::cmpxchg_ptr
- （2）如果设置之前的owner指向当前线程，说明当前线程再次进入monitor，即重入锁，执行 recursions ++ ，记录重入的次数。
- （3）如果当前线程是第一次进入该monitor，设置recursions为1，_owner为当前线程，该线程成功获 得锁并返回。
- （4） 如果获取锁失败，则等待锁的释放。
到这里我自认为作为java程序员就没必要再进一步去深究JVM源码了，因为从上面的介绍其实已经可以知道，当JVM遇到monitorenter指令时会调用C++的代码为当前线程去抢占锁对象对应的monitor的所有权。那可以想像当JVM遇到monitorexit指令时肯定也会调用C++的代码释放monitor的所有权，并唤醒其他线程（源码为src/share/vm/runtime/objectMonitor.cpp中的ObjectMonitor::exit方法， 有兴趣的可以自己去研究）。
做个小图进行总结一下：
4 为什么说monitor是重量级锁
我这里并不想去细究什么是用户态、内核态或者用户空间、内核空间 — 有兴趣的可以自行百度。
因此这里只简单给出两句话：
-
（1）争抢锁+释放锁的C++代码里会调用一些内核函数。
-
（2）简单理解就是，JVM调用了内核提供的函数，期间肯定要涉及到cpu从JVM（用户态）到内核态的来回切换 — 这种切换会带来大量的系统资源消耗，所以说monitor是一个重量级锁。
应该知道的事
- （1）JDK1.6之前JVM遇到monitorenter字节码指令时会直接去抢monitor锁，也就是说无论被synchronized关键字修饰的代码块或方法
是否正在并发执行，都会涉及到用户态和内核态的切换 。- 但有研究表明程序大多数情况下都不会遇到并发的情况
— 这就是JDK1.6之前synchronized关键字面临的最大的尴尬，
— 或许这也是Doug Lea最看不惯的地方 —> 下篇文章将讲一下Doug Lea在ReentrantLock中针对该问题的解决方案
- 但有研究表明程序大多数情况下都不会遇到并发的情况
- （2）虽然JDK1.6对synchronized关键字进行了优化，但是应该要明确的是monitor锁仍然存在，也就是说使用synchronized关键字有可能最终还是要进行用户态和内核态的切换
- 其实这个问题是避免不了的，因为线程挂起（park）和挂起线程的唤醒（unpark）本身就是在进行用户态和内核态的切换。
- JDK1.6及之后对synchronized关键字的优化，本质上是对会出现并发问题的代码在抢锁时、在
没有真正并发执行时等特殊时机进行的优化，以及锁的粒度等进行的优化 —》并不是说就杜绝了用户态和内核态的切换； - 当真正出现并发时，无论是Doug Lea搞得JUC还是synchronized关键字都不可避免的要对抢不到锁的线程进行挂起（park）、对被挂起的线程进行唤醒（unpark）等操作 — 从而会进行用户态和内核态的切换。
end
