文末 JVM 思维导图，有须要的自取
熟知并发编程的你认为上面这段代码的执行后果是怎么样的？
我如果说，执行流程是：
- t1 线程和 t2 线程始终执行 num 的累加操作
- 主线程睡眠 1 秒，1 秒之后醒过来打印此时的 num 值
- 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 个条件，也是会进入平安点的：
- VMThread 处于失常运行状态
- 设计了进入平安点的间隔时间
- 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 知识点，依照本人了解思路整顿成了一个思维导图。
有须要的能够自取就行，如果图片被平台压缩了，你能够公众号后盾回 JVM 获取高清图片。
须要强调的是，这是我整顿的知识点，外面的常识并不是我原创的。
我没有发明常识，只是分享本人如何学习和了解常识。
思维导图的制作参照了大量的书籍和博客，包含但不限于《深刻了解 Java 虚拟机》、美团技术团队文章、阿里技术团队文章、R 大的文章、寒泉子大大的调优文章。
好了，明天的文章就到此结束了。
我是 CoderW，一个有时候喜爱钻牛角尖的程序员，咱们下期再见！