日本欧美不卡一区二区,伊人色综合网一区二区三区,自拍亚洲欧美卡通另类

統(tǒng)計結果顯示：

正常每分鐘都有5秒左右的中斷。
在11:29～11:30之間，中斷頻次陡增，這恰恰是問題現(xiàn)象開始出現(xiàn)的時間段。每分鐘的中斷總時間甚至高達20～30秒。

這就好比，一段1公里的馬路上，正常是遇不見任何紅綠燈的，現(xiàn)在突然增加了幾十個紅綠燈，實在是讓人崩潰。這些中斷很好的解釋了“所有的線程都在做CPU計算，然而CPU資源很閑”的現(xiàn)象。
04 關于Safepoint的調查
Safepoint有多種類型，為了確認Safepoint的具體類型，繼續(xù)讓現(xiàn)場同學協(xié)助，在jvm.options中添加如下參數(shù)，打開JVM日志：

-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=10
-XX:+UnlockDiagnosticVMOptions
-XX:-DisplayVMOutput
-XX:+LogVMOutput
-XX:LogFile=<vm_log_path>

等待問題再次復現(xiàn)的過程中，我基于ES運行日志中統(tǒng)計了每一分鐘的讀寫請求頻次：

讀寫請求次數(shù)是相對平穩(wěn)的，這排除了用戶請求陡增方面的原因。
拿到JVM日志時，看到大量的Safepoint類型為ForceSafepoint：

而偏向鎖回收相關的Safepoint卻應該是長這樣的：

這讓我疑惑了。開始在網(wǎng)上搜索ForceSafepoint的觸發(fā)原因，結果，一無所獲。
查看hotspot的源碼，發(fā)現(xiàn)至少有5種相關場景：

可見，F(xiàn)orceSafepoint是一個“雜燴”，就像統(tǒng)計圖中的“Others”一項。從這里開始，我將JDK加入到了“重點嫌疑人”清單中。
繼續(xù)分析JVM日志。在每一條Safepoint日志中，同時記錄了當時的線程總數(shù)(threads: total一列)：

回顧一下，出現(xiàn)問題時，三個節(jié)點的線程總數(shù)有明顯出入，問題發(fā)生后，線程總數(shù)是增多的，尤其是Lucene Merge Threads 。
“多個Lucene Merge任務”與“陡增的ForceSafepoint/STW中斷”，哪個是“因”哪個是“果”？
依據(jù)JVM日志中統(tǒng)計了每一分鐘的ForceSafepoint次數(shù)，以及線程總數(shù)的變化。將兩條曲線疊加在一起，得到下圖：

從圖中來看，似乎是ForceSafepoint逐步增多在先，后面的線程才逐步增多。也就是說，STW中斷變多在先，然后多個Merge任務線程才開始逐步積累，就好比，一條目錄上突然增設了多個紅綠燈，然后這條目錄逐步變得擁堵。
此時，開始請教Kona JDK團隊的同學，我把GC日志以及thread dump日志分享給了他，并把我目前為止的發(fā)現(xiàn)都告訴了他，最大的懷疑點就是這些不正常的ForceSafepoints，我需要了解ForceSafepoints的原因。
過了一段時間后，他回復我：這個是arm版本的jdk 。因缺乏arm編譯機應急柜，暫時沒法給我提供一個debug版本的arm jdk 。
突然明白，我犯了”先入為主”的錯誤，盡管一開始就意識到需要對環(huán)境進行調查。
難怪在本地X86環(huán)境中始終無法復現(xiàn) 。難怪網(wǎng)上搜索ForceSafepoint時一無所獲。
接下來和客戶電話會議溝通時，獲知：