写个续集,填坑来了!关于“Thread.sleep(0)这一行‘看似无用’的代码”里面留下的坑。
你好呀,我是居家十三天只出了一次小区门的歪歪。
这篇文章是来填坑的,我以前写文章的时候也会去填之前的一些坑,但是由于拖延症,大多都会隔上上几个月。
这次这个坑比较新鲜,就是之前发布的《没有二十年功力,写不出这一行“看似无用”的代码!》这篇文章,太多太多的朋友看完之后问出了一个相同的问题:
首先非常感谢阅读我文章的朋友,同时也特别感谢阅读的过程中带着自己的思考,提出有价值的问题的朋友,这对我而言是一种正反馈。
我当时写的时候确实没有想到这个问题,所以当突然问起的时候我大概知道原因,由于未做验证,所以也不敢贸然回答。
于是我寻找了这个问题的答案,所以先说结论:
就是和 JIT 编译器有关。由于循环体中的代码被判定为热点代码,所以经过 JIT 编译后 getAndAdd 方法的进入安全点的机会被优化掉了,所以线程不能在循环体能进入安全点。
是的,被优化了,我打这个词都感觉很残忍。
接下来我准备写个“下集”,告诉你我是怎么得到这个结论的。但是为了让你丝滑入戏,我先带你简单的回顾一下“上集”。
另外,先把话说在前面,这知识点吧,属于可能一辈子都遇不到的那种。因此我把它划分到我写的“没有卵用系列”,看着也就图一乐。
好了,在之前的那篇文章中,我给出了这样的一个测试用例:
public class MainTest {
public static AtomicInteger num = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
Runnable runnable=()->{
for (int i = 0; i < 1000000000; i++) {
num.getAndAdd(1);
}
System.out.println(Thread.currentThread().getName()+"执行结束!");
};
Thread t1 = new Thread(runnable);
Thread t2 = new Thread(runnable);
t1.start();
t2.start();
Thread.sleep(1000);
System.out.println("num = " + num);
}
}
按照代码来看,主线程休眠 1000ms 后就会输出结果,但是实际情况却是主线程一直在等待 t1,t2 执行结束才继续执行。
运行结果是这样的:
其实我在这里埋了“彩蛋”,这个代码虽然你直接粘贴过去就能跑,但是如果你的 JDK 版本高于 10,那么运行结果就和我前面说的不一样了。
从结果来看,还是有不少人挖掘到了这个“彩蛋”:
所以看文章的时候,有机会自己亲自验证一下,说不定会有意外收获的。
针对程序表现和预期不一致的问题,第一个解决方案是这样的:
把 int 修改为 long 就搞定了。至于为什么,之前的文章中已经说明了,这里就不赘述了。
关键的是下面这个解决方案,所有的争议都围绕着它展开。
受到 RocketMQ 源码的启示,我把代码修改为了这样:
从运行结果上来看 ,即使 for 循环的对象是 int 类型,也可以按照预期执行。
为什么呢?
因为在上集中关于 sleep 我通过查阅资料得出了这样的两个结论:
1.正在执行 native 函数的线程可以看作“已经进入了safepoint”。 2.由于 sleep 方法是 native 的,所以调用 sleep 方法的线程会进入 Safepoint。
论点清晰、论据合理、推理完美、事实清楚,所以上集演到这里就结束了...
直到,有很多朋友问出了这个问题:
可是 num.getAndAdd 底层也是 native 方法调用啊?
对啊,和 sleep 方法一样,这也是 native 方法调用啊,完全符合前面的结论啊,它为什么不进入安全点呢,为什么要搞差别对待呢?
大胆假设
看到问题的时候,我的第一反应就是先把锅甩给 JIT 吧,毕竟除了它,其他的我也实在想(不)不(了)到(解)。
为什么我会直接想到 JIT 呢?
因为循环中的这一行的代码属于典型的热点代码:
num.getAndAdd(1);
引用《深入理解JVM虚拟机》里面的描述,热点代码,主要是分为两类:
被多次调用的方法。 被多次执行的循环体。
前者很好理解,一个方法被调用得多了,方法体内代码执行的次数自然就多,它成为“热点代码”是理所当然的。
而后者则是为了解决当一个方法只被调用过一次或少量的几次,但是方法体内部存在循环次数较多的循环体,这样循环体的代码也被重复执行多次,因此这些代码也应该认为是“热点代码”。很明显,我们的示例代码就属于这种情况。
在我们的示例代码中,循环体触发了热点代码的编译动作,而循环体只是方法的一部分,但编译器依然必须以整个方法作为编译对象。
因为编译的目标对象都是整个方法体,不会是单独的循环体。
既然两种类型都是“整个方法体”,那么区别在于什么地方?
区别就在于执行入口(从方法第几条字节码指令开始执行)会稍有不同,编译时会传入执行入口点字节码序号(Byte Code Index,BCI)。
这种编译方式因为编译发生在方法执行的过程中,因此被很形象地称为“栈上替换”(On Stack Replacement,OSR),即方法的栈帧还在栈上,方法就被替换了。
说到 OSR 你就稍微耳熟了一点,是不是?毕竟它也偶现于面试环节中,作为一些高(装)阶(逼)面试题存在。
其实也就这么回事。
好,概念就先说到这里,剩下的如果你想要详细了解,可以去翻阅书里面的“编译对象与触发条件”小节。
我主要是为了引出虚拟机针对热点代码搞了一些优化这个点。
基于前面的铺垫,我完全可以假设如下两点:
1.由于 num.getAndAdd 底层也是 native 方法调用,所以肯定有安全点的产生。 2.由于虚拟机判定 num.getAndAdd 是热点代码,就来了一波优化。优化之后,把本来应该存在的安全点给干没了。
小心求证
其实验证起来非常简单,前面不是说了吗,是 JIT 优化搞的鬼,那我直接关闭 JIT 功能,再跑一次,不就知道结论了吗?
如果关闭 JIT 功能后,主线程在睡眠 1000ms 之后继续执行,说明什么?
说明循环体里面可以进入 safepoint,程序执行结果符合预期。
所以结果是怎么样的呢?
我可以用下面的这个参数关闭 JIT:
-Djava.compiler=NONE
然后再次运行程序:
可以看到关闭 JIT 之后,主线程并没有等待子线程运行结束后才输出 num。效果等同于前面说的把 int 修改为 long,或者加入 Thread.sleep(0) 这样的代码。
因此我前面的那两点假设是不是就成立了?
好,那么问题就来了,说好的是小心求证,但是我这里只是用了一个参数关闭了 JIT,虽然看到了效果,但是总感觉中间还缺点东西。
缺什么东西呢?
前面的程序我已经验证了:经过 JIT 优化之后,把本来应该存在的安全点给干没了。
但是这句话其实还是太笼统了,经过 JIT 优化之前和之后,分别是长什么样子的呢,能不能从什么地方看出来安全点确实是没了?
不能我说没了就没了,这得眼见为实才行。
诶,你说巧不巧。
我刚好知道有个东西怎么去看这个“优化之前和之后“。
有个工具叫做 JITWatch,它就能干这个事儿。
https://github.com/AdoptOpenJDK/jitwatch
如果你之前没用过这个工具的话,可以去查查教程。不是本文重点,我就不教了,一个工具而已,不复杂的。
我把代码贴到 JITWatch 的沙箱里面:
然后点击运行,最后就能得到这样的一个界面。
左边是 Java 源码,中间是 Java 字节码,右边是 JIT 之后的汇编指令:
我框起来的部分就是 JIT 分层编译后的不同的汇编指令。
其中 C2 编译就是经过充分编译之后的高性能指令,它于 C1 编译后的汇编代码有很多不同的地方。
这一部分如果之前没接触过,看不懂没关系,也很正常,毕竟面试也不会考。
我给你截这几张的意思就是表明,你只要知道,我现在已经可以拿到优化之前和之后的汇编指令了,但是他们自己的差异点很多,那么我应该关注的差异点是什么呢?
就像是给你两个文本,让你找出差异点,很容易。但是在众多差异点中,哪个是我们关心的呢?
这个才是关键问题。
我也不知道,但是我找到了下面这一篇文章,带领我走向了真相。
关键文章
好了,前面都是一些不痛不痒的东西,这里的这篇文章才是关键点:
http://psy-lob-saw.blogspot.com/2015/12/safepoints.html
因为我在这个文章中,找到了 JIT 优化之后,应该关注的“差异点”是什么。
这篇文章的标题叫做《安全点的意义、副作用以及开销》:
作者是一位叫做 nitsanw 的大佬,从他博客里面的文章看,在 JVM 和性能优化方面有着很深的造诣,上面的文章就发布于他的博客。
这是他的 github 地址:
https://github.com/nitsanw
用的头像是一头牦牛,那我就叫他牛哥吧,毕竟是真的牛。
同时牛哥就职于 Azul 公司,和 R 大是同事:
他这篇文章算是把安全点扒了个干净,但是内容非常多,我不可能面面俱到,只能挑和本文相关度非常大的地方进行简述,但是真的强烈建议你读读原文。文章也分为了上下两集,这是下集的地址:
http://psy-lob-saw.blogspot.com/2016/02/wait-for-it-counteduncounted-loops.html
看完之后,你就知道,什么叫做透彻,什么叫做:
在牛哥的文章中分为了下面这几个小节:
What's a Safepoint?(啥是安全点?) When is my thread at a safepoint?(线程啥时候处于安全点?) Bringing a Java Thread to a Safepoint。(将一个Java线程带到一个安全点) All Together Now。(搞几个例子跑跑) Final Summary And Testament。(总结和嘱咐)
和本文重点相关的是“将一个Java线程带到一个安全点”这个部分。
我给你解析一下:
这一段主要在说 Java 线程需要每隔一个时间间隔去轮询一个“安全点标识”,如果这个标识告诉线程“请前往安全点”,那么它就进入到安全点的状态。
但是这个轮询是有一定的消耗的,所以需要 keep safepoint polls to a minimum,也就是说要减少安全点的轮询。因此,关于安全点轮询触发的时间就很有讲究。
既然这里提到轮询了,那么就得说一下我们示例代码里面的这个 sleep 时间了:
有的读者把时间改的短了一点,比如 500ms,700ms 之类的,发现程序正常结束了?
为什么?
因为轮询的时间由 -XX:GuaranteedSafepointInterval 选项控制,该选项默认为 1000ms:
所以,当你的睡眠时间比 1000ms 小太多的时候,安全点的轮询还没开始,你就 sleep 结束了,当然观察不到主线程等待的现象了。
好了,这个只是随口提一句,回到牛哥的文章中,他说综合各种因素,关于安全点的轮询,可以在以下地方进行:
第一个地方:
Between any 2 bytecodes while running in the interpreter (effectively)
在解释器模式下运行时,在任何 2 个字节码之间都可以进行安全点的轮询。
要理解这句话,就需要了解解释器模式了,上个图:
从图上可以知道,解释器和编译器之间是相辅相成的关系。
另外,可以使用 -Xint 启动参数,强制虚拟机运行于“解释模式”:
我们完全可以试一试这个参数嘛:
程序正常停下来了,为什么?
刚刚才说了:
在解释器模式下运行时,在任何 2 个字节码之间都可以进行安全点的轮询。
第二个地方:
On 'non-counted' loop back edge in C1/C2 compiled code
在 C1/C2 编译代码中的 "非计数 "循环的每次循环体结束之后。
关于这个“计数循环”和“非计算循环”我在上集里面已经说过了,也演示过了,就是把 int 修改为 long,让“计数循环”变成“非计算循环”,就不赘述了。
反正我们知道这里说的没毛病就行。
第三个地方:
这是前半句:Method entry/exit (entry for Zing, exit for OpenJDK) in C1/C2 compiled code.
在 C1/C2 编译代码中的方法入口或者出口处(Zing 为入口,OpenJDK 为出口)。
前半句很好理解,对于我们常用的 OpenJDK 来说,即使经过了 JIT 优化,但是在方法的入口处还是设置了一个可以进行安全点轮询的地方。
主要是关注后半句:
Note that the compiler will remove these safepoint polls when methods are inlined.
当方法被内联时编译器会删除这些安全点轮询。
这不就是我们示例代码的情况吗?
本来有安全点,但是被优化没了。说明这种情况是真实存在的。
然后我们接着往下看,就能看到我一直在找的“差异点”了:
牛哥说,如果有人想看到安全点轮询,那么可以加上这个启动参数:
-XX:+PrintAssembly
然后在输出里面找下面的关键词:
如果是 OpenJDK,就找 {poll} 或 {poll return} ,这就是对应的安全点指令。 如果是 Zing,就找 tls.pls_self_suspend 指令
实操一把就是这样的:
确实找到了类似的关键字,但是在控制台输出的汇编太多了,根本没法分析。
没关系,这不重要,重要的是我到了这个关键的指令:{poll}
也就是说,如果在初始的汇编中有 {poll} 指令,但是在经过 JIT 充分优化之后的代码,也就是前面说的 C2 阶段的汇编指令里面,找不到 {poll} 这个指令,就说明安全点确实是被干掉了。
所以,在 JITWatch 里面,当我选择查看 for 循环(热点代码)在 C1 阶段的编译结果的时候,可以看看有 {poll} 指令:
但是,当我选择 C2 阶段的编译结果的时候,{poll} 指令确实都找不到了:
接着,如果我把代码修改为这样,也就是前面说的会正常结束的代码:
正常结束,说明循环体内可以进入安全点,也就是说明有 {poll} 指令。
所以,再次通过 JITWarch 查看 C2 的汇编,果然看到了它:
为什么呢?
从最终输出的汇编上来看,因为 Thread.sleep(0) 这行代码的存在,阻止了 JIT 做过于激进的优化。
那么为什么 sleep 会阻止 JIT 做过于激进的优化呢?
好了,
别问了,
就到这吧,
再问,
就不礼貌了。
牛哥的案例
牛哥的文章中给了下面五个案例,每个案例都有对应的代码:
Example 0: Long TTSP Hangs Application Example 1: More Running Threads -> Longer TTSP, Higher Pause Times Example 2: Long TTSP has Unfair Impact Example 3: Safepoint Operation Cost Scale Example 4: Adding Safepoint Polls Stops Optimization
我主要带大家看看第 0 个和第 4 个,老有意思了。
第 0 个案例
它的代码是这样的:
public class WhenWillItExit {
public static void main(String[] argc) throws InterruptedException {
Thread t = new Thread(() -> {
long l = 0;
for (int i = 0; i < Integer.MAX_VALUE; i++) {
for (int j = 0; j < Integer.MAX_VALUE; j++) {
if ((j & 1) == 1)
l++;
}
}
System.out.println("How Odd:" + l);
});
t.setDaemon(true);
t.start();
Thread.sleep(5000);
}
}
牛哥是这样描述这个代码的:
他说这个代码应该是在 5 秒之后结束,但是实际上它会一直运行下去,除非你用 kill -9 命令强行停止它。
但是当我把代码粘贴到 IDEA 里面运行起来,5 秒之后,程序停了,就略显尴尬。
我建议你也粘出来跑一下。
这里为什么和牛哥说的运行结果不一样呢?
评论区也有人问出了这个问题:
于是牛哥又写了一篇下集,详细的解释了为什么:
http://psy-lob-saw.blogspot.co.za/2016/02/wait-for-it-counteduncounted-loops.html
简单来说就是他是在 Eclipse 里面跑的,而 Eclipse 并不是用的 javac 来编译,而是用的自己的编译器。
编译器差异导致字节码的差异,从而导致运行结果的差异:
然后牛哥通过一顿分析,给出了这样的一段代码,
和之前的代码唯一不一样的地方,就是在子线程里面调用 countOdds 方法之前,在主线程里面先进行了 10w 次的运行调用。
这样改造之后代码运行起来就不会在 5 秒之后停止了,必须要强行 kill 才行。
为什么呢?
别问,问就是答案就在他的下集里面,自己去翻,写的非常详细。
同时在下集中,牛哥还非常贴心的给你贴出了他总结的六种循环的写法,那些算是“counted Loops”,建议仔细辨别:
第 4 个案例
这个案例是一个基准测试,牛哥说它是来自 Netty 的一个 issue:
这里怎么突然提到 Netty 了呢?
牛哥给了一个超链接:
https://github.com/netty/netty/pull/3969#issuecomment-132559757
这个 pr 里面讨论的内容非常的多,其中一个争论的点就是循环到底用 int 还是 long。
这个哥们写了一个基准测试,测试结果显示用 int 和 long 似乎没啥差别:
需要说明的是,为了截图方便,我截图的时候把这个老哥的基准测试删除了。如果你想看他的基准测试代码,可以通过前面说的链接去找到。
然后这个看起来头发就很茂盛的老哥直接用召唤术召唤了牛哥:
等了一天之后,牛哥写了一个非常非常详细的回复,我还是只截取其中一部分:
他上来就说前面的老哥的基准测试写的有点毛病,所以看起来差不多。你看看我写的基准测试跑出来的分,差距就很大了。
牛哥这里提到的基准测试,就是我们的第四个案例。
所以也可以结合着 Netty 的这个特别长的 pr 去看这个案例,看看什么叫做专业。
最后,再说一次,文中提到的牛哥的两篇文章,建议仔细阅读。
另外,关于安全点的源码,我之前也分享过这篇文章,建议一起食用,味道更佳:《关于安全点的那点破事儿》
我只是给你指个路,剩下的路就要你自己走了,天黑路滑,灯火昏暗,小心脚下,不要深究,及时回头,阿弥陀佛!
最后,感谢你阅读我的文章。欢迎关注公众号【why技术】,文章全网首发哦。