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

文末 JVM 思维导图，有需要的自取

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

我如果说，执行流程是：

1. t1 线程和 t2 线程一直执行 num 的累加操作

2. 主线程睡眠 1 秒，1 秒之后醒过来打印此时的 num 值

3. t1 线程和 t2 线程继续执行加 1 的操作，直到执行完 「2 亿」 次累加操作

你赞成吗？

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

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

「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。

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

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

安全点日志

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

可以看到，这段代码的执行一共进行了三次进入安全点。

其中第二个 EnableBiasedLocking 是 JVM 延时开启偏向锁的操作，这个也比较有意思，不过不是文章的重点，下次有机会再说。

我们重点关注的是第一个 「no vm operation」 操作。将这段日志单独拿出来，在参数说明上加上中文解释：

总结来说就是：

JVM 想执行 「no vm operation」 ，这个操作需要线程都进入安全点，整个期间一共有 12 个线程，正在运行的线程有 2 个，需要等待这两个线程进入安全点，等待这 2 个线程进入安全点并阻塞耗费了 5037 毫秒。

要找出这两个线程也很简单，它不是需要 5000 多毫秒才进入安全点吗，我就加上参数让进入安全点时间超过 5000 毫秒的线程超时就行了。

于是加上 -XX:+SafepointTimeout 和 -XX:SafepointTimeoutDelay=5000 参数，执行代码。

哦豁，这不就是 t1 和 t2 线程吗。

这个结果也是意料之中的，我们的重点是这个 「no vm operation」 到底是个什么操作？凭什么让主线程等这么久？

源码定位

这个 VM 操作的名字叫做 「no vm operation」 ，翻译成中文就是「不是 VM 操作」，连起来就是不是 VM 操作的 VM 操作？

一个不是 VM 操作的操作居然也能让全局进入安全点？

那到底是什么操作呢？知识盲区了呀！

一顿谷歌百度，也没有找到一个比较信服的答案。

于是乎，我决定看 JVM 的源码。

在 JVM 源码里面全局搜索 「no vm operation」 ，发现只有 safepoint.cpp 有这个信息。

点击去一看，果然，一下子定位到打印日志的地方，就是这个 SafepointSynchronize::print_statistics() 方法。

其中有一句很关键的代码：

_vmop_type == -1 ?     "no vm operation" :     VM_Operation::name(sstats->_vmop_type)

这是一个三目运算：如果 _vmop_type 等于 -1，打印的安全点日子操作类型那一栏就会输出 「no vm operation」 。

而这个 _vmop_typen 呢，是结构体 SafepointStats 中的一个成员，具体的含义是「触发安全点的 VM 操作类型」。

那什么操作类型会将 _vmop_type 设置成 -1 呢？

我在开启安全点方法里面找到了答案：

如果不是 VM 操作触发的安全点事件，这个时候就会将 _vmop_type 设置成 -1。

也就是说还有其他情况也可以触发安全点事件，让所有线程进入安全点。

那么，我们只需要找到触发安全点事件对应的代码就行了。

一个个文件找太难，换个思路，想要进入安全点，必定要调用进入安全点的方法。

而进入安全点的方法就是 safepoint.cpp 里面的 SafepointSynchronize::begin() 方法。

我们只需要全局搜一下哪里调用了这个 SafepointSynchronize::begin() 这个方法应该就能找到触发安全点事件对应的代码。

全局搜索发现只有 vmThread.cpp 里面有调用，vmThread.cpp 封装的都是 VMThread 相关的方法。

VMThread

VMThread 是个什么东西呢？

VMThread 是 JVM 自身启动的一个内部线程，它主要用来协调其它线程达到安全点以及执行 VM 操作。

VM 操作这个概念全文已经多次提到了，那到底有哪些操作是 VM 操作呢？

我们比较熟悉的 CMS 的初始标记和最终标记都是 VM 操作，又比如 thread dump，线程挂起以及偏向锁的撤销等等都是 VM 操作。

VM 操作类型有很多，JVM 对应的源码在 vm_operations.hpp 定义的宏 VM_OPS_DO 里面。

宏 VM_OPS_DO 里面的每个 VM 操作，基本上都有一个单独的子类去实现。

VMThread 里面有个 VMOperationQueue 队列，用于存放一个一个连在一起的 VM 操作。

VMThread 循环执行 VM 操作的方法，叫做 VMThread::loop() 方法。

loop() 方法是 VMThread 的核心方法，该方法不断从 VMOperationQueue 队列中获取待执行的 VM 操作，然后调用每种 VM 操作具体的实现 evaluate() 方法执行不同的逻辑。

这里用了策略模式，VMThread 执行逻辑是固定的，只负责调度，而每种 VM 操作需要根据需求自己实现 evaluate() 方法。

答案出现

而我们上面苦苦寻找的 no vm operation 原因，就在 VMThread 的 loop() 方法里面。

从源码可以看到，在 VM 操作为空的情况下，只要满足以下 3 个条件，也是会进入安全点的：

1. VMThread 处于正常运行状态

2. 设计了进入安全点的间隔时间

3. SafepointALot 是否为 true 或者是否需要清理

程序正常运行 VMThread 肯定能正常运行，所以条件 1 能满足。

用 「java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal 2>&1 | grep Safepoint」 命令查看 JVM 关于安全点的默认参数，发现 GuaranteedSafepointInterval 默认设置成了 1 秒，所以条件 2 也能满足。

对于条件 3，SafepointALot 默认为 false，那要想条件 3 能满足的话，必须 SafepointSynchronize::is_cleanup_needed()为 true。

点进去看它的具体实现：

通过追踪代码，可以发现 SafepointSynchronize::is_cleanup_needed() 就是判断 StubQueue 里面是否有 stub 缓存。

那 StubQueue 是什么呢？stub 又是什么呢？

这涉及 JVM 的模板解释器和编译器了，由于篇幅有限，下次有机会的话继续深入探讨。

我用一句话概括就是 「JVM 执行期间的编译解释代码缓存」。

清理 stub 你可以简单的理解成「清理代码缓存」。

也就是说，在 JVM 正常运行的时候，如果设置了进入安全点的间隔，就会隔一段时间判断是否有代码缓存要清理，如果有，会进入安全点。

这个触发条件不是 VM 操作，所以会将 _vmop_type 设置成-1，输出日志的时候打印对应的 「no vm operation」，也就是我们看到的安全点日志。

而文章开头的代码执行效果，主线程一直在等待 t1 和 t2 进入安全点，正是触发了这个条件。

再次验证推论

回过头来再看文章开头的代码，通过加上 -XX:GuaranteedSafepointInterval = 0 将进入安全点间隔时间设置成 0，也就是关闭定时进入安全点，看看代码运行结果是怎么样的。

-XX:GuaranteedSafepointInterval 是诊断性质的参数，需要加上-XX:+UnlockDiagnosticVMOptions 参数解锁诊断参数方可使用。

从运行结果上可以看到，关闭过一段时间进入安全点的设置之后，主线程睡了 1 秒后，不再需要等待 t1 和 t2 线程循环执行完，睡完之后马上就打印了此时的 num 值。

这样的运行结果，也再一次的验证了我们的推论。

间隔一秒进入安全点的设置还是有它的作用的，我建议你别去动它。

-XX:GuaranteedSafepointInterval 是个诊断性质的参数，不建议线上使用。

从网上的文献来看，关掉这个参数也有可能会造成一些未知错误，具体是什么错误我也没有遇见过，也不知道是真是假。

总之，线上环境谨慎一点总没错，如果你对 JVM 底层不是很熟悉的话，我建议还是别去动它。

有趣的注释

知识点分享到这里就结束了，分享一个有趣的事情。

在我追踪 JVM 源码的过程中，我发现编写 StubQueue 的作者留下了这样一段注释：

我润色翻译一下就是：「在你不能证明你改的没问题的时候，别特么乱动我代码，这段代码比你想象中牛逼的多」。

看到没有，这就是大神的骄傲和自信！

反观我呢，我平时给代码写注释的时候，只敢在上面写：「如果你看到我的代码有 BUG，麻烦帮我修一下，谢谢了」。

从写注释的骄傲和自信上就能看得出，我和大神差距有多大了。

我一定要加油，以后也能写出这样霸气的注释！

思维导图

我把我个人觉得重要的 JVM 知识点，按照自己理解思路整理成了一个思维导图。

有需要的可以自取就行，如果图片被平台压缩了，你可以关注公众号「CoderW」后台回 「JVM」 获取高清图片。

需要强调的是，这是我整理的知识点，里面的知识并不是我原创的。

我没有创造知识，只是分享自己如何学习和理解知识。

思维导图的制作参照了大量的书籍和博客，包括但不限于《深入理解 Java 虚拟机》、美团技术团队文章、阿里技术团队文章、R 大的文章、寒泉子大大的调优文章。

好了，今天的文章就到此结束了。

我是 CoderW，一个有时候喜欢钻牛角尖的程序员，我们下期再见！