阅读 240

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

原文链接: blog.csdn.net

这是《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队列;
四、线程B释放锁的时候,从_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源码,时间关系未能详尽分析,有兴趣的同学可以继续深入学习,我也很期待和您一起学习共同进步。

文章分类
后端