線上服務的FGC問題排查，看這篇就夠了！

線上服務的GC問題，是Java程序很是典型的一類問題，很是考驗工程師排查問題的能力。同時，幾乎是面試必考題，可是能真正答好此題的人並很少，要麼原理沒吃透，要麼缺少實戰經驗。

過去半年時間裏，咱們的廣告系統出現了屢次和GC相關的線上問題，有Full GC過於頻繁的，有Young GC耗時過長的，這些問題帶來的影響是：GC過程當中的程序卡頓，進一步致使服務超時從而影響到廣告收入。

這篇文章，我將以一個FGC頻繁的線上案例做爲引子，詳細介紹下GC的排查過程，另外會結合GC的運行原理給出一份實踐指南，但願對你有所幫助。內容分紅如下3個部分：

一、從一次FGC頻繁的線上案例提及

二、GC的運行原理介紹

三、排查FGC問題的實踐指南

01 從一次FGC頻繁的線上案例提及

去年10月份，咱們的廣告召回系統在程序上線後收到了FGC頻繁的系統告警，經過下面的監控圖能夠看到：平均每35分鐘就進行了一次FGC。而程序上線前，咱們的FGC頻次大概是2天一次。下面，詳細介紹下該問題的排查過程。

1. 檢查JVM配置

經過如下命令查看JVM的啓動參數：
ps aux | grep "applicationName=adsearch"

-Xms4g -Xmx4g -Xmn2g -Xss1024K
-XX:ParallelGCThreads=5
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+UseCMSCompactAtFullCollection
-XX:CMSInitiatingOccupancyFraction=80

能夠看到堆內存爲4G，新生代爲2G，老年代也爲2G，新生代採用ParNew收集器，老年代採用併發標記清除的CMS收集器，當老年代的內存佔用率達到80%時會進行FGC。

進一步經過 jmap -heap 7276 | head -n20 能夠得知新生代的Eden區爲1.6G，S0和S1區均爲0.2G。

2. 觀察老年代的內存變化

經過觀察老年代的使用狀況，能夠看到：每次FGC後，內存都能回到500M左右，所以咱們排除了內存泄漏的狀況。

3. 經過jmap命令查看堆內存中的對象

經過命令 jmap -histo 7276 | head -n20

上圖中，按照對象所佔內存大小排序，顯示了存活對象的實例數、所佔內存、類名。能夠看到排名第一的是：int[]，並且所佔內存大小遠遠超過其餘存活對象。至此，咱們將懷疑目標鎖定在了 int[] .

4. 進一步dump堆內存文件進行分析

鎖定 int[] 後，咱們打算dump堆內存文件，經過可視化工具進一步跟蹤對象的來源。考慮堆轉儲過程當中會暫停程序，所以咱們先從服務管理平臺摘掉了此節點，而後經過如下命令dump堆內存：

jmap -dump:format=b,file=heap 7276

經過JVisualVM工具導入dump出來的堆內存文件，一樣能夠看到各個對象所佔空間，其中int[]佔到了50%以上的內存，進一步往下即可以找到 int[] 所屬的業務對象，發現它來自於架構團隊提供的codis基礎組件。

5. 經過代碼分析可疑對象

經過代碼分析，codis基礎組件每分鐘會生成約40M大小的int數組，用於統計TP99 和 TP90，數組的生命週期是一分鐘。而根據第2步觀察老年代的內存變化時，發現老年代的內存基本上也是每分鐘增長40多M，所以推斷：這40M的int數組應該是重新生代晉升到老年代。

咱們進一步查看了YGC的頻次監控，經過下圖能夠看到大概1分鐘有8次左右的YGC，這樣基本驗證了咱們的推斷：由於CMS收集器默認的分代年齡是6次，即YGC 6次後還存活的對象就會晉升到老年代，而codis組件中的大數組生命週期是1分鐘，恰好知足這個要求。

至此，整個排查過程基本結束了，那爲何程序上線前沒出現此問題呢？經過上圖能夠看到：程序上線前YGC的頻次在5次左右，這次上線後YGC頻次變成了8次左右，從而引起了此問題。

6. 解決方案

爲了快速解決問題，咱們將CMS收集器的分代年齡改爲了15次，改完後FGC頻次恢復到了2天一次，後續若是YGC的頻次超過每分鐘15次還會再次觸發此問題。固然，咱們最根本的解決方案是：優化程序以下降YGC的頻率，同時縮短codis組件中int數組的生命週期，這裏就不作展開了。

02 GC的運行原理介紹

上面整個案例的分析過程當中，其實涉及到不少GC的原理知識，若是不懂得這些原理就着手處理，其實整個排查過程是很抓瞎的。

這裏，我選擇幾個最核心的知識點，展開介紹下GC的運行原理，最後再給出一份實踐指南。

1. 堆內存結構

你們都知道: GC分爲YGC和FGC，它們均發生在JVM的堆內存上。先來看下JDK8的堆內存結構：

能夠看到，堆內存採用了分代結構，包括新生代和老年代。新生代又分爲：Eden區，From Survivor區（簡稱S0），To Survivor區（簡稱S1區），三者的默認比例爲8:1:1。另外，新生代和老年代的默認比例爲1:2。

堆內存之因此採用分代結構，是考慮到絕大部分對象都是短生命週期的，這樣不一樣生命週期的對象可放在不一樣的區域中，而後針對新生代和老年代採用不一樣的垃圾回收算法，從而使得GC效率最高。

2. YGC是何時觸發的？

大多數狀況下，對象直接在年輕代中的Eden區進行分配，若是Eden區域沒有足夠的空間，那麼就會觸發YGC（Minor GC），YGC處理的區域只有新生代。由於大部分對象在短期內都是可收回掉的，所以YGC後只有極少數的對象能存活下來，而被移動到S0區（採用的是複製算法）。

當觸發下一次YGC時，會將Eden區和S0區的存活對象移動到S1區，同時清空Eden區和S0區。當再次觸發YGC時，這時候處理的區域就變成了Eden區和S1區（即S0和S1進行角色交換）。每通過一次YGC，存活對象的年齡就會加1。

3. FGC又是何時觸發的？

下面4種狀況，對象會進入到老年代中：

一、YGC時，To Survivor區不足以存放存活的對象，對象會直接進入到老年代。

二、通過屢次YGC後，若是存活對象的年齡達到了設定閾值，則會晉升到老年代中。

三、動態年齡斷定規則，To Survivor區中相同年齡的對象，若是其大小之和佔到了 To Survivor區一半以上的空間，那麼大於此年齡的對象會直接進入老年代，而不須要達到默認的分代年齡。

四、大對象：由-XX:PretenureSizeThreshold啓動參數控制，若對象大小大於此值，就會繞過新生代, 直接在老年代中分配。

當晉升到老年代的對象大於了老年代的剩餘空間時，就會觸發FGC（Major GC），FGC處理的區域同時包括新生代和老年代。除此以外，還有如下4種狀況也會觸發FGC：

一、老年代的內存使用率達到了必定閾值（可經過參數調整），直接觸發FGC。

二、空間分配擔保：在YGC以前，會先檢查老年代最大可用的連續空間是否大於新生代全部對象的總空間。若是小於，說明YGC是不安全的，則會查看參數 HandlePromotionFailure 是否被設置成了容許擔保失敗，若是不容許則直接觸發Full GC；若是容許，那麼會進一步檢查老年代最大可用的連續空間是否大於歷次晉升到老年代對象的平均大小，若是小於也會觸發 Full GC。

三、Metaspace（元空間）在空間不足時會進行擴容，當擴容到了-XX:MetaspaceSize 參數的指定值時，也會觸發FGC。

四、System.gc() 或者Runtime.gc() 被顯式調用時，觸發FGC。

4. 在什麼狀況下，GC會對程序產生影響？

無論YGC仍是FGC，都會形成必定程度的程序卡頓（即Stop The World問題：GC線程開始工做，其餘工做線程被掛起），即便採用ParNew、CMS或者G1這些更先進的垃圾回收算法，也只是在減小卡頓時間，而並不能徹底消除卡頓。

那到底什麼狀況下，GC會對程序產生影響呢？根據嚴重程度從高到底，我認爲包括如下4種狀況：

一、FGC過於頻繁：FGC一般是比較慢的，少則幾百毫秒，多則幾秒，正常狀況FGC每隔幾個小時甚至幾天才執行一次，對系統的影響還能接受。可是，一旦出現FGC頻繁（好比幾十分鐘就會執行一次），這種確定是存在問題的，它會致使工做線程頻繁被中止，讓系統看起來一直有卡頓現象，也會使得程序的總體性能變差。

二、YGC耗時過長：通常來講，YGC的總耗時在幾十或者上百毫秒是比較正常的，雖然會引發系統卡頓幾毫秒或者幾十毫秒，這種狀況幾乎對用戶無感知，對程序的影響能夠忽略不計。可是若是YGC耗時達到了1秒甚至幾秒（都快遇上FGC的耗時了），那卡頓時間就會增大，加上YGC自己比較頻繁，就會致使比較多的服務超時問題。

三、FGC耗時過長：FGC耗時增長，卡頓時間也會隨之增長，尤爲對於高併發服務，可能致使FGC期間比較多的超時問題，可用性下降，這種也須要關注。

四、YGC過於頻繁：即便YGC不會引發服務超時，可是YGC過於頻繁也會下降服務的總體性能，對於高併發服務也是須要關注的。

其中，「FGC過於頻繁」和「YGC耗時過長」，這兩種狀況屬於比較典型的GC問題，大機率會對程序的服務質量產生影響。剩餘兩種狀況的嚴重程度低一些，可是對於高併發或者高可用的程序也須要關注。

03 排查FGC問題的實踐指南

經過上面的案例分析以及理論介紹，再總結下FGC問題的排查思路，做爲一份實踐指南供你們參考。

1. 清楚從程序角度，有哪些緣由致使FGC？

一、大對象：系統一次性加載了過多數據到內存中（好比SQL查詢未作分頁），致使大對象進入了老年代。

二、內存泄漏：頻繁建立了大量對象，可是沒法被回收（好比IO對象使用完後未調用close方法釋放資源），先引起FGC，最後致使OOM.

三、程序頻繁生成一些長生命週期的對象，當這些對象的存活年齡超過度代年齡時便會進入老年代，最後引起FGC. （即本文中的案例）

四、程序BUG致使動態生成了不少新類，使得 Metaspace 不斷被佔用，先引起FGC，最後致使OOM.

五、代碼中顯式調用了gc方法，包括本身的代碼甚至框架中的代碼。

六、JVM參數設置問題：包括總內存大小、新生代和老年代的大小、Eden區和S區的大小、元空間大小、垃圾回收算法等等。

2. 清楚排查問題時能使用哪些工具

一、公司的監控系統：大部分公司都會有，可全方位監控JVM的各項指標。

二、JDK的自帶工具，包括jmap、jstat等經常使用命令：

查看堆內存各區域的使用率以及GC狀況
jstat -gcutil -h20 pid 1000

查看堆內存中的存活對象，並按空間排序
jmap -histo pid | head -n20

dump堆內存文件
jmap -dump:format=b,file=heap pid

三、可視化的堆內存分析工具：JVisualVM、MAT等

3. 排查指南

一、查看監控，以瞭解出現問題的時間點以及當前FGC的頻率（可對比正常狀況看頻率是否正常）

二、瞭解該時間點以前有沒有程序上線、基礎組件升級等狀況。

三、瞭解JVM的參數設置，包括：堆空間各個區域的大小設置，新生代和老年代分別採用了哪些垃圾收集器，而後分析JVM參數設置是否合理。

四、再對步驟1中列出的可能緣由作排除法，其中元空間被打滿、內存泄漏、代碼顯式調用gc方法比較容易排查。

五、針對大對象或者長生命週期對象致使的FGC，可經過 jmap -histo 命令並結合dump堆內存文件做進一步分析，須要先定位到可疑對象。

六、經過可疑對象定位到具體代碼再次分析，這時候要結合GC原理和JVM參數設置，弄清楚可疑對象是否知足了進入到老年代的條件才能下結論。

04 最後的話

這篇文章經過線上案例並結合GC原理詳細介紹了FGC的排查過程，同時給出了一份實踐指南。

後續會以相似的方式，再分享一個YGC耗時過長的案例，但願能幫助你們吃透GC問題排查，若是以爲本文對你有幫助，請你們關注個人我的公衆號！

- End -

做者簡介：程序員，985碩士，前亞馬遜Java工程師，現58轉轉技術總監。持續分享技術和管理方向的文章。若是感興趣，可微信掃描下面的二維碼關注個人公衆號：『IT人的職場進階』