線上環(huán)境 FGC 頻繁，如何解決？

前言

這個問題應(yīng)該是 Java 面試中很經(jīng)常被問到的一個題目，很多人害怕這個題目。

因為大部分人可能在工作中根本遇不到 FGC 頻繁的問題，即使從網(wǎng)上背了點答案，心里也不踏實，因為畢竟不是自己親自接觸和解決過。

今天就和大家聊聊面試過程中遇到這個問題，該如何解答。

你不知道的面試官

大多數(shù)人面試會有一個情況，把面試官想的很“高大”，感覺面試官應(yīng)該“上知天文下知地理”，自己只是從網(wǎng)上背了個答案，肯定會被看穿，從而導(dǎo)致心虛。

但是大部分事實是，很多面試官也一樣沒有遇到過這個問題，因為頻繁 FGC 本身就是一個很小概率的場景。即使遇到過，大部分其實都是一些很簡單的原因。所以，如果充分準(zhǔn)備好之后，其實可以更自信一些。

面試時如何解答

下面以我自身為例，談?wù)勅绻业姆?wù)遇到線上環(huán)境 FGC 頻繁時，我們是如何解決的。

我們的流程我覺得是比較規(guī)范的，可以用來做面試答案，也可以用來實際使用。

1、明確分工

這個步驟應(yīng)該是在事前就已經(jīng)明確好的，類似于一個故障處理流程規(guī)范，這邊需要明確出3個主要角色：

1）總指揮

負(fù)責(zé)故障處理整體指揮的人，例如快速拉起線上/線下會議、通知到系統(tǒng)核心同學(xué)，對各同學(xué)工作進(jìn)行分工等等。

該角色一般由主管來擔(dān)任，或者主管指定的另一個同學(xué)。

2）故障恢復(fù)小組

負(fù)責(zé)故障恢復(fù)的同學(xué)，該部分同學(xué)的任務(wù)就是讓系統(tǒng)以最快的速度恢復(fù)正常。

3）故障定位小組

負(fù)責(zé)故障定位的同學(xué)，該部分同學(xué)的任務(wù)就是定位出問題的根本原因。

大部分同學(xué)的回答可能會集中在故障定位中，但其實另外兩個角色也是非常重要的，在線上出現(xiàn)問題時，止損永遠(yuǎn)是放在第一位，其次才是定位。

2、故障恢復(fù)

2.1、線上發(fā)布導(dǎo)致

查看故障服務(wù)近期是否存在上線操作，如果有的話優(yōu)先采取回滾解決。

分析：該場景應(yīng)該是最常見的場景，就是剛上的代碼存在bug。

2.2、非線上發(fā)布導(dǎo)致

1）小面積故障

如果故障機(jī)器只是發(fā)布在少量機(jī)器，例如：某機(jī)臺機(jī)器、某個機(jī)房機(jī)器、某個地域的機(jī)器、某個泳道的機(jī)器等等。

此時優(yōu)先采取禁用服務(wù)器解決，禁用前先評估禁用這批機(jī)器后是否存在服務(wù)容量問題，如果是則先擴(kuò)容。

分析：該場景一般是代碼存在bug，但是該場景的使用頻率很低，所以上線時沒暴露出來，只是偶爾會被觸發(fā)到。也是出現(xiàn)概率比較大的場景。

2）大面積故障

如果故障機(jī)器不存在共性，這個概率說實話非常非常小，但是如果碰到了，故障恢復(fù)小組能做的事情就比較有限了。

因為這個場景大概率是代碼存在bug，同時發(fā)布時沒有被大量觸發(fā)，而是到現(xiàn)在才被大量觸發(fā)，需要定位才能根本解決。

此時，故障恢復(fù)小組能做的就是使用擴(kuò)容、重啟、限流等手段，來盡量維持服務(wù)的運轉(zhuǎn)，同時給故障定位爭取時間。

分析：之所以說該場景概率小是因為，分布在大量機(jī)器上的故障通常是使用頻率高的場景，這部分場景一般在服務(wù)發(fā)布時就會暴露出問題，而不是發(fā)布很久之后。但是這個場景也是確實存在的，但是會比較少。

3、故障定位

故障定位主要是用于應(yīng)對故障恢復(fù)中的最后一個場景，也是將故障恢復(fù)和故障定位分成兩個小組并行執(zhí)行的主要原因。

3.1、FGC 能正常回收到內(nèi)存

通過監(jiān)控或GC日志，我們能看到每次FGC后都能正常回收到內(nèi)存，但是內(nèi)存很快又被占滿，導(dǎo)致又出現(xiàn)FGC，從而出現(xiàn)FGC頻繁。

這個場景通常可能由于兩個原因?qū)е拢?/span>

1）Eden 區(qū)配置太小，導(dǎo)致大量對象直接進(jìn)入老年代，從而導(dǎo)致老年代快速被占滿。

2）業(yè)務(wù)量較大，特別是在業(yè)務(wù)高峰期。而當(dāng)前的服務(wù)器配置已經(jīng)無法滿足當(dāng)前的業(yè)務(wù)量。

對于這兩個原因，代碼本身可能沒有大問題，優(yōu)先采取擴(kuò)容機(jī)器，降低單臺服務(wù)器壓力即可解決。

后續(xù)則需要重新評估當(dāng)前服務(wù)器的配置是否滿足當(dāng)前的業(yè)務(wù)量，JVM參數(shù)是否存在優(yōu)化空間等等。

分析：該場景是由于業(yè)務(wù)量增大沒有及時評估或者JVM參數(shù)配置存在問題導(dǎo)致的，整體來說，出現(xiàn)的概率較小。

3.2、FGC 不能正常回收到內(nèi)存

通過監(jiān)控或GC日志，我們能看到每次FGC后只能回收到很小的空間，甚至回收不到空間，從而出現(xiàn)FGC頻繁。

對于這個場景，二話不說，先dump下內(nèi)存，使用工具看下當(dāng)前的內(nèi)存泄漏情況、內(nèi)存分布情況等等，查看是哪個對象占用了大量內(nèi)存。具體工具常見的例如 Eclipse MAT，如果公司內(nèi)部有封裝的工具就更好了。

通常查看完內(nèi)存占用情況，大概率會看到個別對象占用了大量的內(nèi)存，結(jié)合其引用鏈定位出在代碼中的位置。

接著就是根據(jù)代碼分析問題的嚴(yán)重程度：

如果是小概率觸發(fā)的場景，大部分請求其實正常，則可以先禁用問題機(jī)器，后續(xù)上線修復(fù)即可。

如果是大概率觸發(fā)的場景，則查看是否存在降級開關(guān)，如果有則優(yōu)先降級解決，如果沒有則只能修改代碼，走緊急修復(fù)流程。

總結(jié)
整體的解決流程其實還是比較簡單的，沒有太復(fù)雜的東西。大多數(shù)情況下，用好擴(kuò)容、禁用、重啟這幾個常見手段即可解決大部分問題。
個人經(jīng)驗而言，線上頻繁FGC問題90%以上是由于開發(fā)同學(xué)代碼存在問題導(dǎo)致的，例如常見的存在死循環(huán)、開無界隊列等等。以上的問題在dump后，很容易就能定位到根本原因。
而如果遇到諸如依賴的第三方j(luò)ar存在bug導(dǎo)致的問題，例如Guava、Log4j，這種場景一般是在極端情況下出才會出現(xiàn)，所以一般只會出現(xiàn)在少數(shù)機(jī)器，禁用即可臨時解決，然后后續(xù)再慢慢排查。

最后
我是囧輝，一個堅持分享原創(chuàng)技術(shù)干貨的程序員，如果覺得本文對你有幫助，記得點贊關(guān)注，我們下期再見。

推薦閱讀
Java 基礎(chǔ)高頻面試題（2021年最新版）
Java 集合框架高頻面試題（2021年最新版）
面試必問的 Spring，你懂了嗎？
面試必問的 MySQL，你懂了嗎？

最近我將面試：阿里、字節(jié)、美團(tuán)、快手、拼多多等大廠的高頻面試整理出來，并按大廠的標(biāo)準(zhǔn)給出自己的解析。
群里有不少同學(xué)看完拿下了阿里、美團(tuán)等大廠 Offer，希望能助你一臂之力，早日拿下大廠 Offer。
獲取方式：關(guān)注公眾號回復(fù)【面試】即可領(lǐng)取，更多大廠面試真題解析 PDF 整理中。