小陈：牛逼的老王，快来了，我的笔记本已经准备好了，开讲了......
老王：哈哈，好，搞起来......
老王：我们这一章节接着上一章的内容继续讲下去，本章讲解的是synchronized是怎么通过monitor进行重量级加锁？
老王：在讲synchronized是怎么通过monitor进行重量级加锁之前，我们先回顾一下上一章的那个Mark Word用途的表格：
当Mark Word的最后两位的锁标志位是10的时候，Mark Word这哥们说自己处于重量级锁的模式，重量级加锁不是它的责任，是monitor的责任，它作为mark word记录的数据是monitor的地址，让我们自己去找monitor去进行加锁。
老王：小陈啊，上一章说的对象头和Mark Word的知识点还记得吧，不记得要回去再回顾下哦。
小陈：哈哈，哪能啊，老王，上一章的知识点已经完全在我脑子里了。
上一章说了对象的基本结构，以及对象头中的Mark Word的含义，其中非常重要的就是当Mark Word中最后两位的锁标志位是10的时候，Mark Word的前面是monitor监视器的地址，我现在就给你画出来对象头、Mark Word 和 monitor之间的关系图：
老王：哈哈，就知道小陈你聪明，啥都记住了，那我也就不啰嗦了......
老王：那我下面就直接说monitor这玩意了......
monitor
老王：我先解释一下monitor是个啥东西：
monitor叫做对象监视器、也叫作监视器锁，JVM规定了每一个java对象都有一个monitor对象与之对应，这monitor是JVM帮我们创建的，在底层使用C++实现的。
老王：其实monitor在底层也是某个类的对象，那个类就是ObjectMonitor，它拥有的属性也字段如下：
ObjectMonitor() {
_header;
_count ; // 非常重要，表示锁计数器，_count = 0表示还没人加锁，_count > 0 表示加锁的次数
_waiters;
_recursions;
_owner; // 非常重要，指向加锁成功的线程，_owner = null 时候表示没人加锁
_waitset; // wait线程的集合，在synchorized代码块中调用wait()方法的线程会被加入到此集合中沉睡，等待别人叫醒它
_waitsetLock;
_responsiable;
_succ;
_cxq;
_freenext;
_entrylist; // 非常重要，等待队列，加锁失败的线程会被加入到这个等待队列中，等待再次争抢锁
_spinFreq; // 获取锁之前的自旋的次数
_spinclock; // 获取之前每次锁自旋的时间
ownerIsThread;
}
老王：小陈，上面我说的monitor的一些属性，其中加锁非常重要的属性，你能看懂不？
小陈：知道monitor有哪些属性，怎么通过这些属性加锁的还是完全不懂啊......
老王：没关系，慢慢来；我首先给你解释一波有哪些关键的属性，然后跟你说怎么通过这些属性加锁的。
小陈：好滴，老王就是nice啊......
monitor对象的关键属性
老王：那我就给你解释一波:
_count : 这个属性非常重要，直接表示有没有被加锁，如果没被线程加锁则 _count=0，如果 _count大于0则说明被加锁了
_owner：这个属性也非常重要，直接指向加锁的线程，比如线程A获取锁成功了，则 _owner = 线程A；当 _owner = null的时候表示没线程加锁
_waitset：当持有锁的线程调用wait() 方法的时候，那个线程就会释放锁，然后线程被加入到monitor的waitset集合中等待，然后线程就会被挂起。只有有别的线程调用notify将它唤醒。
_entrylist：这个就是等待队列，当线程加锁失败的时候被block住，然后线程会被加入到这个entrylist队列中，等待获取锁。
_spinFreq：获取锁失败前自旋的次数；JDK1.6之后对synchronized进行优化；原先JDK1.6以前，只要线程获取锁失败，线程立马被挂起，线程醒来的时候再去竞争锁，这样会导致频繁的上下文切换，性能太差了。
JDK1.6后优化了这个问题，就是线程获取锁失败之后，不会被立马挂起，而是每个一段时间都会重试去争抢一次，这个 _spinFreq就是最大的重试次数，也就是自旋的次数，如果超过了这个次数抢不到，那线程只能沉睡了。
_spinClock：上面说获取锁失败每隔一段时间都会重试一次，这个属性就是自旋间隔的时间周期，比如50ms，那么就是每隔50ms就尝试一次获取锁。
老王：下面我就画图告诉你通过这些属性是怎么进行加锁的？
（1）首先呢，没有线程对monitor进行加锁的时候是这样的：
_count = 0 表示加锁次数是0，也就是没线程加锁； _owner 指向null，也就是没线程加锁
（2）然后呢，这个时候线程A、线程B来竞争加锁了，如下图所示：
（3）线程A竞争到锁，将 _count 修改为1，表示加锁次数为1，将_owner = 线程A，也就是指向自己，表示线程A获取到了锁。
老王：讲到这里，聪明的小陈，你知道monitor加锁的原理是啥了没？
小陈：哈哈，老王，你上面刚刚把图画出来的时候，我就知道了。
在 _count = 0，_owner = null的时候，表示monitor没人加锁，这个时候线程A和线程B同时请求加锁，也就是竞争将_count改为1，由于线程A这哥们动作比较快，它将 _count改为1，获取锁成功了。它还嘚瑟了一下，同时将 _onwer = 线程A，表示自己获取了锁，告诉线程B，兄弟不好意思了，是我获取了锁，我先去操作了。
老王：哈哈，很好，小陈你理解能力越来越好了......
小陈：老王啊，既然加锁就是将 _count 设置为1，同时将 _owner 指向自己。
那反过来推测，释放锁的时候是不是将_count 设置为 0 , 将 _owner 设置为 null 就 OK了？
老王：没错，就是这样的，释放锁的过程就是这么简单......
小陈：加锁和释放锁我看懂了，那monitor的其它属性是用来干啥的？
老王：我们慢慢来，接着上面的_count和_owner属性，我们接下来将的是 _spinFreq、_spinclock、_entrylist这几个东西：
上面说过 _spinFreq是等待锁期间自旋的次数、 _spinclock是自旋的周期也就是每次自旋多久时间、 _entrylist这个就是自旋次数用完了还没获取锁，只能放到 _entrylist等待队列挂起了。
让我们继续接着图来讲：
（1）首先线程B获取锁的时候发现monitor已经被线程A加锁了
（2）然后monitor里面记录的 _spinFreq 、spinclock 信息告诉线程B，你可以每隔50ms来尝试加锁一次，总共可以尝试10次
（3）如果线程B在10次尝试加锁期间，获取锁成功了，那线程B将 _count 设置为 1， _owner 指向自己表示自己获取锁成功了
（4）如果10次尝试获取锁此时都用完了，那没辙了，它只能放到等待队列里面先睡觉去了，也就是线程B被挂起了
老王：这样将上面的_spinFreq、_spinclock、_entryList这几个参数，小陈你听懂了没？
小陈：听懂了，也就是说_spinFreq和_spinclock 这两个monitor的属性主要是让线程自旋的时候使用的吧，而entryList作用是当线程自旋次数都用完了之后，只能进入等待队列进行休眠了，这样我就懂了......
老王：没错，就是这样......
小陈：牛逼啊，其实我还有个疑问啊，为啥线程B请求失败之后不直接进入队列挂起？而是要自旋之后再次尝试获取锁？为啥不是一直自旋然后尝试获取锁，而是要设置一个最大尝试次数？
获取锁失败后的自旋操作
老王：这个啊，其实跟jvm获取monitor锁的优化有关，我来跟你讲讲这么做有什么好处:
（1）首先跟你说下，线程挂起之后唤醒的代价很大，底层涉及到上下文切换，用户态和内核态的切换，我打个比方可能最少耗时3000ms这样，这只是打个比方哈
（2）线程A获取了锁，这个时候线程B获取失败。按照上面自旋的数据 _spinclock = 50ms（每次自旋50ms）， _spinFreq = 10（最多10次自旋）
（3）假如线程A使用的时间很短，比如只使用150ms的时间；那么线程B自旋3次后就能获取到锁了，也就花费了150ms左右的时间，相比于挂起之后唤醒最少花费3000ms的时间，是不是大大减少了等待时间啊......，这也就提高了性能了。
（4）如果不设置自旋的次数限制，而是让它一直自旋。假如线程A这哥们耗时特别的久，比如它可能在里面搞一下磁盘IO或者网络的操作，花了5000ms！！。
那线程B可不能在那一直自旋着等着它吧，毕竟自旋可是一直使用CPU不释放CPU资源的，CPU这时也在等着不能干别的事，这可是浪费资源啊，所以啊自旋次数也是要有限制的，不能一直等着，否则CPU的利用率大大被降低了。
所以在10次自旋之后，也就是500ms之后，还获取失败，那就把自己挂起，释放CPU资源咯。
举例说明：
我就举个例子，假如有两个人要上厕所，但是只有一个坑位，线程A去得比较早，先把坑位给占了：
（1）假如线程A加锁了，它只是上了个小厕所，用了150ms就完成了；然后线程B尝试几次之后就能获取成功了
（2）但是如果线程A拉肚子了，这家伙在里面蹲了一个多小时....，线程B尝试了10次之后，发现坑还是没有空的。 这个时候线程B发现自己还有好多代码没写，害~，不等了，先释放CPU去写写代码，待会再来看看......
小陈：牛逼啊，老王，你这么一说我全懂了。你上班是不是经常去...，所以才这么深的体会......
老王：滚......
小陈：嘿嘿，我好想发现了什么......
老王：打住打住...，看看现在时间九点半了，给你讲完后面的_waitset我就回家了，我女儿还等着我回去呢...
小陈：好的，老王，那我们抓紧时间吧。
monitor的wait和notify
老王：说起monitor里面的waitset，上面讲的就是一个集合。
必须是当线程获取锁之后，才能调用wait()方法，然后此时释放锁，将_count恢复为0，将_owner指向 null，然后将自己加入到waitset集合中，等待别人调用notify或者notifyAll将其中waitset的线程唤醒
小陈：notify和notifyAll有啥区别啊？
老王：简单说就是notify就是从waitset中随机挑一个线程来唤醒，只唤醒一个。notifyAll这方法就是将waitset中所有等着的线程全部唤醒了。
小陈：哦哦，原来是这样啊
老王：我们继续，假如说现在有个场景是这样的......
线程A执行如下代码：
synchronized(this) { if (某个条件) { wait(); } }
线程B执行如下代码：
synchronized(this) { // 某些业务逻辑 ...... notify(); }
下面画个图来说一下：
（1）首先啊还是线程A这哥们动作比较快，先获取到了锁。
（2）然后线程A发现条件不满足，想了想，算了，我先释放锁，睡个觉，等条件满足了，别人再唤醒我，岂不是美滋滋。于是释放了锁，睡觉去了
（3）然后线程B自己可以加锁了，执行了一些业务逻辑，然后去调用notify方法唤醒线程A，嘿兄弟，别睡了，到你了...
（4）线程A醒来之后，还是要再去去竞争锁的，也就是醒来之后还要竞争将_count修改为1，竞争_owner指向自己，毕竟它还在synchronized代码块内部嘛，只有获取锁之后才能执行synchronized代码块的代码。所以只有它再次获取到锁了之后，才会执行代码块内部的逻辑
老王：小陈，我这么说，你听懂了没......
小陈：懂了懂了，原来是这样啊......
小陈：听了老王你的讲解，我终于知道wait和notify的原理了，也知道为啥要结合synchronized一起使用了。因为waitset集合是monitor对象的一个属性，所以调用之前必须要获取到monitor对象的操作权限，也就是获取到锁，notify要操作waitset也是一样。
所以wait和notify方法之后在获取了锁之后才能调用的，所以才需要写在synchronized方法块的内部啊，进入synchronized获取锁了之后才能执行啊
老王：没错，就是这样的......
小陈：听了老王你的讲解，之前网上的那些讨论我终于也明白了......
老王：什么讨论，说了听听
小陈：网上有人说wait() 和 Thread.sleep()的区别，说wait()会释放锁，而Thread.sleep()不释放锁，现在我终于知道了：
synchronized(this) { // 这个时候线程释放锁，然后将自己放入monitor的waitset队列， // 等待别人调用notify/notifyAll将唤醒 wait(); }
synchronized(this) { // 这种情况不释放锁，就是睡个500ms然后醒来持有锁继续干活 Thread.sleep(500); }
老王：你说的没错，这是这样的...
小陈：哈哈，老王你真牛逼啊，懂得真多，这么底层的道理到了你这都使用很简单的方式讲明白了...
老王：得了得了，不吹牛逼，我该回去了，我女儿还等着我呢......
小陈：等等啊老王，我们下一章讨论啥啊？
老王：下一章《synchronized的锁升级原理？锁消除、无锁、偏向锁、轻量级锁、重量级锁、重量级锁自旋》，记得准时到场啊。
小陈：好的，老王，我们下一章见。
