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

前言

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

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

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

你不知道的面試官

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

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

面試時如何解答

下面以我自身為例，談談如果我的服務遇到線上環(huán)境 FGC 頻繁時，我們是如何解決的。

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

1、明確分工

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

1）總指揮

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

該角色一般由主管來擔任，或者主管指定的另一個同學。

2）故障恢復小組

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

3）故障定位小組

負責故障定位的同學，該部分同學的任務就是定位出問題的根本原因。

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

2、故障恢復

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

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

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

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

1）小面積故障

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

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

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

2）大面積故障

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

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

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

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

3、故障定位

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

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

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

這個場景通?？赡苡捎趦蓚€原因?qū)е拢?/span>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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