熟知併發編程的你認爲下面這段代碼的執行結果是怎麼樣的？
我如果說，執行流程是：
- 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，麻煩幫我修一下，謝謝了。
從寫註釋的驕傲和自信上就能看得出，我和大神差距有多大了。
我一定要加油，以後也能寫出這樣霸氣的註釋！