Java的wait()、notify()学习三部曲之三：修改JVM源码控制抢锁顺序

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码)： https://github.com/zq2599/blog_demos

本篇概览

• 这是《Java的wait()、notify()三部曲》系列的最后一章，前两章请看《Java的wait()、notify()学习三部曲之一：JVM源码分析》、《Java的wait()、notify()学习三部曲之二：修改JVM源码看参数》。
• 在前两章中，我们先阅读分析和同步相关的JVM源码，再修改源码把关键参数Policy和QMode打印出来，对锁的抢占和释放有了清楚认识，这里结合NotifyDemo.java源码对我们之前的分析做个回顾，NotifyDemo.java源码在github上，地址是：git@github.com:zq2599/blog_demos.git，里面有多个工程，这次实战用的是下图红框中这个：

• 对Demo执行的总结如下：

一、线程B持有锁；
二、 线程A在wait的时候被唤醒，进入_EntryList队列(Policy等于2时的逻辑)；
三、线程C抢不到锁，进入_cxq队列；
四、线程Ｂ释放锁的时候，从_EntryList中取出A唤醒，A竞争锁（QMode等于0时的逻辑）；
五、线程A释放锁的时候，_EntryList中为空，所以从_cxq中取出C唤醒，C竞争锁（QMode等于0时的逻辑）;

• 从上述分析可以看出，从wait中醒来的A总是比BLOCKING的C先抢占到锁，是因为QMode等于0时JVM先从_EntryList中取线程去竞争锁导致的，我们先来回顾一下QMode的值决定的逻辑：
• QMode = 2的操作最特殊：取_cxq队列首元素唤醒；
• QMode等于其他值的操作如下：
• 一、QMode = 3，把_cxq队列的首元素放入_EntryList尾部，然后执行步骤四；
• 二、QMode = 4，把_cxq队列的首元素放入_EntryList头部，然后执行步骤四；
• 三、QMode = 0，不做什么，执行步骤4；
• 四、如果_EntryList非空，就取首元素唤醒，否则取_cxq的首元素唤醒；
• 现状是这样的：A在_EntryList列，C在_cxq队列；
• 综上所述，如果QMode=2，就会直接从_cxq中取出C线程唤醒，这样C就比A先拿到锁了！
• 开始行动吧，启动docker，打开objectMonitor.cpp文件，找到void ATTR ObjectMonitor::exit(bool not_suspended, TRAPS)方法，找到“int QMode = Knob_QMode ;”这段代码，在下面加一行"QMode = 2;"，如下图所示：

• 改完，编译构建JDK吧，对编译有疑问的同学请看《极速体验编译openjdk8（docker环境）》，编译完成后，回到目录/usr/local/openjdk/build/linux-x86_64-normal-server-slowdebug/jdk/bin，执行命令./java NotifyDemo再次执行demo程序，得到结果如下图所示，线程C比线程A先抢到锁了：

• 这就结束了？当然没有，还记得之前对QMode的分析么，QMode等于4的时候，会把线程C从_cxq队列取出来放在_EntryList队列的头部，这样在_EntryList中C就排在A前面了，接下来就会从_EntryList头部取出线程唤醒，所以，QMode等于4的时候，C也会比A先抢到锁。
• 修改objectMonitor.cpp源码，把QMode赋值为4，再次编译后，执行./java NotifyDemo，可以看到如下结果：

• 完全符合预期！
• 至此，对JVM的同步机制的学习就结束了，过程中涉及到很多JVM源码，时间关系未能详尽分析，有兴趣的同学可以继续深入学习，我也很期待和您一起学习共同进步。

欢迎关注阿里云开发者社区博客：程序员欣宸

学习路上，你不孤单，欣宸原创一路相伴...