没有发生GC也进入了安全点？这段关于安全点的JVM源码有点意思

熟知并发编程的你认为下面这段代码的执行结果是怎么样的？

image

我如果说，执行流程是：

1. t1 线程和 t2 线程一直执行 num 的累加操作
2. 主线程睡眠 1 秒，1 秒之后醒过来打印此时的 num 值
3. t1 线程和 t2 线程继续执行加 1 的操作，直到执行完 2亿 次累加操作

你赞成吗？

我的猜想看起来没什么问题，但实际运行效果证明了我是错的，下面是运行动图：

image

从运行动图上可以看到，将代码跑起来之后，却发现实际执行结果是这样的：

1 秒之后，主线程并没有马上打印 num，而是等 t1 和 t2 分别执行完 2 亿次累加操作退出循环后，才会打印 num 的值。

这个结果和预想的不一样。我是基于 JDK1.8 跑的，你也可以试试。

为什么会这样呢？

答案是：

JVM 想要执行某个操作，让所有线程进入安全点，但是 t1 和 t2 线程因为 JIT 对可数循环的过渡优化必须等循环跑完了才进入安全点，所以主线程一直在等 t1 和 t2，迟迟不能输出 num 的值。

可数循环：形如 for (int i = 0; i < 100000000; i++) {...}的循环被称为可数循环

简单来说就是：主线程在等 t1 和 t2 线程进入安全点

这个答案的由来，why 神转载的一篇文章：《真是绝了！这段被 JVM 动了手脚的代码!》中已经说得很清楚了，这里不再重复阐述。

此文就源于我当时的一个疑问：JVM 让线程都进入安全点到底干了什么不为人知的事情？

发生了 GC？

难道是发生了 GC 吗？

第一，代码里面没有创建对象申请内存。

第二，加上 -XX:-PrintGC 也没有打印 GC 日志。

第三，执行 jstat 命令，通过输出日志可以看出，JVM 运行期间各个内存区域都没有发生变化，也没有发生 GC。

image

所以，因为发生了 GC 而需要进入安全点这种情况被排除了。

问题就变成了：没有发生 GC，需要所有的线程都进入安全点干什么？

安全点日志

加上 -XX:+PrintSafepointStatistics 参数，让程序执行的时候打印安全点的相关日志。