記一次JVM FullGC引發嚴重線上事故的定位、分析、解決過程！

這篇文章給大家聊一次線上生產系統事故的解決經歷，其背後代表的是線上生產系統的JVM FullGC可能引發的嚴重故障。

先簡單說說線上生產系統的一個背景，因為僅僅是文章作為案例來講，所以弱化大量的業務背景。

簡單來說，這是一套分散式系統，系統A需要將一個非常核心以及關鍵的資料透過網路請求，傳輸給另外一個系統B。

所以這裡其實就考慮到了一個問題，如果系統A剛剛將核心資料傳遞給了系統B，結果系統B莫名其妙當機了，豈不是會導致資料丟失？

所以在這個分散式系統的架構設計中，採取了非常經典的一個Quorum演算法。

這個演算法簡單來說，就是系統B必須要部署奇數個節點，比如說至少部署3臺機器，或者是5臺機器，7臺機器，類似這樣子。

然後系統A每次傳輸一個資料給系統，都必須要對系統B部署的全部機器都傳送請求，將一份資料傳輸給系統B部署的所有機器。

要判定系統A對系統B的一次資料寫是成功的，要求系統A必須在指定時間範圍內對超過Quorum數量的系統B所在機器傳輸成功。

舉個例子，假設系統B部署了3臺機器，那麼他的Quorum數量就是：3 / 2 + 1 = 2，也就是說系統B的Quorum數量就是：所有機器數量 / 2 + 1。

所以系統A要判定一個核心資料是否寫成功，如果系統B一共部署了3臺機器的話，那麼系統A必須在指定時間內收到2臺系統B所在機器返回的寫成功的響應。

此時系統A才能認為這條資料對系統B是寫成功了。這個就是所謂的Quorum機制。

也就是說，分散式架構下，系統之間傳輸資料，一個系統要確保自己給另外一個系統傳輸的資料不會丟失，必須要在指定時間內，收到另外一個系統Quorum（大多數）數量的機器響應說寫成功。

這套機制實際上在很多分散式系統、中介軟體系統中都有非常廣泛的使用，我們線上的分散式系統也是採用了這個Quorum機制在兩個系統之間傳輸資料。

給大家上一張圖，一起來看一下這套架構長啥樣。

如上圖所示，圖中很清晰的展示了系統A和系統B之間傳輸一份資料時的Quorum機制。

接下來，我們用程式碼給大家展示一下，上面的Quorum寫機制在程式碼層面大概是什麼樣子的。

PS：因為實際這套機制涉及大量的底層網路傳輸、通訊、容錯、最佳化的東西，所以下面程式碼經過了大幅度簡化，僅僅表達出了一個核心的意思。

上面就是經過大幅精簡後的程式碼，不過核心的意思是表達清晰了。大家可以仔細看兩遍，其實還是很容易弄懂的。

這段程式碼其實含義很簡單，說白了就是非同步開啟執行緒傳送資料給系統B所有的機器，同時進入一個while迴圈等待系統B的Quorum數量的機器返回響應結果。

如果超過指定超時時間還沒收到預期數量的機器返回結果，那麼就判定系統B部署的叢集出現故障，接著讓系統A直接退出，相當於系統A當機。

整個程式碼，就是這麼個意思！

光是看程式碼其實沒啥難的，但是問題就在於線上執行的時候，可不是跟你寫程式碼的時候想的一樣簡單。

有一次線上生產系統執行的過程中，整體系統負載都很平穩，本來是不應該有什麼問題，但是結果突然收到報警，說系統A突然當機了。

然後就開始進行排查，左排查右排查，發現系統B叢集都好好的，不應該有問題。

然後再查查系統A，發現系統A別的地方也沒什麼問題。

最後結合系統A自身的日誌，以及系統A的JVM FullGC進行垃圾回收的日誌，我們才算是搞清楚了具體的故障原因。

其實原因非常的簡單，就是系統A線上上執行一段時間後，會偶發性的進行長時間Stop the World的JVM FullGC，也就是大面積垃圾回收。

但是，此時會造成系統A內部的工作執行緒大量的卡頓，不再工作。要等JVM FullGC結束之後，工作執行緒才會恢復運作。

我們來看下面那個程式碼片段：

但是這種系統A的莫名當機是不正確的，因為如果沒有JVM FullGC，本來上面那個if語句是不會成立的。

他會停頓1秒鐘進入下一輪while迴圈，接著就可以收到系統B返回的Quorum數量的結果，這個while迴圈就可以中斷，繼續執行了。

結果因為出現了JVM FullGC卡頓了幾十秒，導致莫名其妙就觸發了if判斷的執行，系統A莫名其妙就退出當機了。

所以，線上JVM FullGC導致的系統長時間卡頓，是造成系統不穩定執行的隱形殺手之一！

至於上述程式碼穩定性的最佳化，也很簡單。我們只要在程式碼里加入一些東西，監控一下上述程式碼中是否發生了JVM FullGC。

如果發生了JVM FullGC，就自動延長expireTime就可以了。

比如下面程式碼的改進：

透過上述程式碼的改進，就可以有效的最佳化線上系統的穩定性，保證其在JVM FullGC發生的情況下，也不會隨意出現異常當機退出的情況了。