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

GC的運作原理介紹

先前分享了一篇GC問題案例分析

• 一次線上JVM調優實踐，FullGC40次/天到10天一次的優化過程
• JVM調優實戰：解決CMS concurrent-abortable-preclean LongGC的問題

整個案例的分析過程中，其實涉及到很多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問題，大機率會對程式的服務品質産生影響。剩餘兩種情況的嚴重程度低一些，但是對于高并發或者高可用的程式也需要關注。

排查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參數設定，弄清楚可疑對象是否滿足了進入到老年代的條件才能下結論。