文末 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，一個有時候喜歡鑽牛角尖的程序員，我們下期再見！
