Full GC 頻率優(yōu)化實(shí)戰(zhàn)

作者：Li Gang 2025-04-24 09:01:37

本文介紹了游戲業(yè)務(wù)使用MAT和GC日志等工具對 Full GC頻率進(jìn)行優(yōu)化的過程。

一、背景

游戲業(yè)務(wù)面對用戶端的某個工程，每天Full GC頻率達(dá)到120次，業(yè)務(wù)高峰期每7分鐘就會有一次Full GC。為了避免情況持續(xù)變差，最大程度減少對系統(tǒng)響應(yīng)時間的負(fù)面影響，需要對該工程的Full GC頻率進(jìn)行優(yōu)化。

該項目JDK版本為1.8，老年代使用CMS作為垃圾回收器，優(yōu)化前的部分啟動參數(shù)如下：

-Xms4608M -Xmx4608M -Xmn2048M -XX:MetaspaceSize=320M -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFractinotallow=92 -XX:+UseCMSInitiatingOccupancyOnly

二、工具介紹

在本次優(yōu)化過程中，我們主要使用了MAT和GC日志作為排查工具。MAT是一個功能強(qiáng)大的內(nèi)存分析工具，而GC日志則用于記錄Java虛擬機(jī)中的垃圾回收行為和內(nèi)存情況。這兩者結(jié)合起來，能夠幫助開發(fā)人員深入分析程序的內(nèi)存使用情況，并進(jìn)行相應(yīng)的優(yōu)化。下文將詳細(xì)的介紹這兩種工具的使用方法，以及對應(yīng)的優(yōu)化案例。

2.1 MAT（Memory Analyzer Tool）

Eclipse Memory Analyzer Tool（MAT）是一個開源的Java堆轉(zhuǎn)儲分析工具。它旨在幫助開發(fā)人員識別和消除Java堆中的內(nèi)存泄漏和優(yōu)化內(nèi)存使用。MAT允許用戶分析Java堆轉(zhuǎn)儲文件，識別對象的內(nèi)存占用情況，查找潛在的內(nèi)存泄漏和冗余對象，以便執(zhí)行一些內(nèi)存優(yōu)化。

使用MAT打開dump文件后，首先進(jìn)入的是上圖頁面，此頁面會顯示dump包的縮略概覽信息，包括堆大小，類數(shù)量，對象數(shù)量等信息。其中的Biggest Objects By Retained Size和Leak Suspects在問題明顯時會比較有用，但對相對復(fù)雜的問題來說幫助不大。筆者比較常用的是下面這幾個功能，下文將依次介紹：

2.1.1 Dominator Tree

（1）功能

展示對象的支配關(guān)系。對象A支配對象B代表從GC Root（也不一定是GC ROOT，也可以是unreachable的起點(diǎn)）達(dá)到對象B的所有路徑都必須經(jīng)過對象A，這也意味著對象A被垃圾回收后，對象B也會被回收。

這個功能相較于下面的Histogram更強(qiáng)調(diào)對象的引用關(guān)系，此外還可以通過Group By Class/Group By Package/Group By ClassLoader來進(jìn)一步的聚合對象。

MAT的各種圖標(biāo)中會頻繁的出現(xiàn)Shallow Heap Size和Retained Heap Size這兩個名詞，其含義如下：

Shallow Heap Size：這個對象自身在堆中的大小
Retained Heap Size：這個對象被垃圾回收后會釋放的堆內(nèi)存大小

上圖中，情況1里對象A的Retained Heap Size = A的Shallow Heap Size + B的Shallow Heap Size +C的Shallow Heap Size，情況2里對象A的Retained Heap Size = A的Shallow Heap Size + B的Shallow Heap Size。

（2）使用方法

①上圖為Group By Class的dominator tree。剛打開dominator tree時默認(rèn)是不進(jìn)行g(shù)roup的，此時可以排查單個大對象，排查完單個大對象后，需要將對象Group一下才能進(jìn)行下一步的排查。

② 從上圖可以看出，這個堆內(nèi)的對象內(nèi)存占用比較分散，說明導(dǎo)致問題的原因可能不止一個，這種情況下只能結(jié)合自身業(yè)務(wù)逐個排查內(nèi)存占用排在前面的對象。

③ 對這些可疑的對象，右鍵類，選擇List objects → with outgoing references展開對象列表，查看這類對象具體存了什么，判斷這些對象的值是否可以再分類。

④ 根據(jù)對象的值，判斷對象的業(yè)務(wù)含義，確定是哪段代碼創(chuàng)建的對象。

⑤ 結(jié)合代碼，思考這類對象是在新生代還是老年代，如果能確定都在新生代，那這些對象一般不會導(dǎo)致老年代快速增長。

⑥如果在老年代，需要確定其是怎么從新生代晉升的，內(nèi)存占用是否有上限，上限是多少，一般多長時間能達(dá)到上限，再確定有沒有問題。

2.1.2 Histogram

功能

histogram可以顯示出各類對象的Shallow Heap Size和Retained Heap Size，Retained Heap Size默認(rèn)不展示，需要點(diǎn)擊菜單欄的Calculate Retained Size進(jìn)行計算，堆較大時計算耗時較長。

這張表一般和Dominator Tree結(jié)合使用，我們能看到char[]占用了較大的內(nèi)存，但由于Dominator Tree里聚合好的char[]都是頂層支配者，上層不會再有引用，有時無法直接確定這些對象曾經(jīng)被誰持有過，這時可以通過Histogram查看同類對象，找到相似的并且reachable的對象來確定這類對象是誰創(chuàng)建的。但是這一步其實(shí)可以通過oql解決，所以這張表在排查過程中的使用率其實(shí)沒有Histogram高。

2.1.3 OQL

功能

MAT提供的一種類似SQL的查詢語句，可以對對象進(jìn)行過濾。這篇官方文章里給了很多查詢語句樣例：https://wiki.eclipse.org/MemoryAnalyzer/OQL，這里就簡單列一些筆者排查過程中用過的語句，不再贅述：

// 字符串模糊匹配
SELECT * FROM char[] b where toString(b) LIKE ".*traceId.*"
// 查找地址>0x700000000的對象
SELECT * FROM java.lang.Object t WHERE  toHex(t.@objectAddress) >= "0x700000000"
// 查找長度等于73并且retained heap size>1000B 的對象
SELECT * FROM java.lang.Object[] a where a.@length=73 and a.@retainedHeapSize>1000
// 查找長度等于65536并且上層有引用的對象
SELECT * FROM char[] a where a.@length=65536 and (inbounds(a).size()>0)

2.2 GC日志

GC日志是記錄Java虛擬機(jī)中垃圾回收活動的日志文件。在GC日志中，可以看到包括垃圾回收的時間、類型（如新生代GC、老年代GC等）、回收周期、回收停頓時間、回收前后堆的使用情況等信息。GC日志打印的信息可以通過以下啟動項控制：

三、案例介紹

在這篇文章中，我們將聚焦于一些具體的案例，涉及到大量被Dubbo的FutureAdapter引用的對象、Jackson的BufferRecycler導(dǎo)致的大量char[65536]以及對象晉升年齡閾值過小等問題。通過這些案例，我們將探討這些具體問題的引起原因以及解決方案。

3.1 大量被Dubbo的FutureAdapter引用的對象

（1）分析過程

從上圖中，我們可以看到dubbo FutureAdapter占用了230M左右的內(nèi)存，前面的PSWMS對象雖然也占用了230M左右的內(nèi)存，但這是業(yè)務(wù)使用的本地緩存相關(guān)對象，其內(nèi)存占用是在預(yù)期范圍內(nèi)的，因此優(yōu)先分析FutureAdapter。先右鍵List objects→with outgoing references展開對象列表。

發(fā)現(xiàn)其中有大量大小幾乎一致的FutureAdapter，一個占用內(nèi)存328KB左右，大小和內(nèi)容幾乎一致的對象約有550多個，總共占用內(nèi)存200M左右。

FutureAdapter被用來執(zhí)行Dubbo的異步調(diào)用，項目使用的dubbo版本為2.7.18。dubbo的同步調(diào)用本質(zhì)上是一個異步轉(zhuǎn)同步的過程，發(fā)起異步調(diào)用將CompletableFuture對象放到ThreadLocal的FutureContext里，然后立刻調(diào)用CompletableFuture.get方法阻塞獲取返回值，獲取到返回值后，dubbo不會主動清理FutureContext，因此該線程的ThreadLocal里會有一條FutureContext→ FutureAdapter→Result的引用，如下圖：

然而，那550多個FutureAdapter均為不可達(dá)對象，意味著其不被ThreadLocal引用，在下次GC時會被回收，不過我們無法直接確定這些對象是在老年代還是新生代，有可能這些對象都在新生代，下次young gc時就會被回收，不會晉升到老年代，更不會導(dǎo)致老年代增長。

但由于這個列表里的數(shù)據(jù)有明確的業(yè)務(wù)含義，可以找到對應(yīng)的業(yè)務(wù)接口，此接口單機(jī)峰值qps約為2，響應(yīng)時間約100ms，每被調(diào)用一次，就會創(chuàng)建一個該對象列表，此時該機(jī)器的young gc頻率約為10s一次。假設(shè)這些對象都在新生代沒有晉升老年代，那么這些對象在新生代最大的存活數(shù)量約為((接口響應(yīng)時間 + 兩次young gc間隔) * 對象創(chuàng)建速度) = (0.1s + 10s) * 2 ≈ 20，而堆里有550多個，如果這些對象沒有晉升到老年代的話數(shù)量上對不上，所以可以推測出這些對象在老年代里，需要等下次Full GC時才會被回收。

那么這些不可達(dá)的FutureAdapter為什么會在老年代？每次執(zhí)行dubbo調(diào)用，dubbo都會用這次調(diào)用的FutureAdapter替換掉上次調(diào)用時存在FutureContext里的FutureAdapter，上次調(diào)用的FutureAdapter不再被GC Root引用，在下次GC時被回收。當(dāng)一個線程相對頻繁的執(zhí)行dubbo調(diào)用時，F(xiàn)utureAdapter會被young gc回收，不會晉升到老年代。但在本例中，該dubbo調(diào)用被放到了corePoolSize=150，maxPoolSize=500的業(yè)務(wù)通用線程池中執(zhí)行，該線程池會執(zhí)行其他不需要調(diào)用dubbo服務(wù)的任務(wù)，并且該線程池的使用率并不高，這就意味著一個線程調(diào)用完dubbo服務(wù)后可能要過一段時間才能執(zhí)行下一次dubbo調(diào)用。

由于這個原因?qū)е翭utureAdapter被放入ThreadLocal后，在新生代停留過長時間，最終晉升到老年代，這個"過長時間"對于此項目來說是6次young gc的間隔時長，這個時長的獲取方法會在后續(xù)說明。

（2）解決方案

對于此業(yè)務(wù)來說，這個dubbo調(diào)用可以改為查詢本地緩存，直接解決了問題。除此之外還有其他解決方案，需要結(jié)合自身業(yè)務(wù)選擇合適的方案。

直接使用dubbo的異步調(diào)用，而不是在上層再創(chuàng)建一個線程池來進(jìn)行調(diào)用。
合理設(shè)置線程池的大小，提高線程的利用率。
寫一個Dubbo Filter，每次同步調(diào)用完后清理FutureContext（影響面可能較大，需自行評估風(fēng)險）。

3.2. Jackson的BufferRecycler導(dǎo)致的大量char[65536]

（1）分析過程

從dominator tree中我們能看到char[]也占用了相當(dāng)大的一部分內(nèi)存，展開char[]，發(fā)現(xiàn)其中包含大量的char[65536]，使用oql統(tǒng)計得知不被gc root引用的有1600個，占用內(nèi)存200M左右，被gc root引用的有500個，這種char[65536]里存儲的數(shù)據(jù)均為http接口返回值反序列化后的字符。其被gc root引用時的鏈路如下，均被ThreadLocal里的BufferRecycler引用：

在Jackson庫中，BufferRecycler的主要作用是管理緩沖區(qū)的重用，可以減少頻繁的內(nèi)存分配和釋放，從而降低垃圾回收的負(fù)擔(dān)，提高性能。但從堆上看，這些char數(shù)組里不可達(dá)的數(shù)量遠(yuǎn)大于可達(dá)的數(shù)量（1600:500），說明其復(fù)用率并不高，與其設(shè)計的目標(biāo)不符，需要查看源碼才能搞清原因。

項目使用jackson的ObjectMapper。

writeValueAsString()方法對http接口返回值進(jìn)行了反序列化，使用的Jackson版本為2.10，該方法完整的執(zhí)行流程如下圖：

簡單來說，jackson在反序列化時，會將反序列化的結(jié)果存儲在多段char[]里，每當(dāng)最后一個char[]空間不夠存放結(jié)果時，就新建一個char[]，大小為最后使用的char[]的1.5倍，但不超過65536，反序列化結(jié)束后將char[]列表拼接起來就得到了結(jié)果，然后線程會將最后使用的那個char[]存放到ThreadLocal。此線程下次反序列化時，會從ThreadLocal取出這個char[]進(jìn)行復(fù)用。這樣的一個復(fù)用邏輯會有一個問題，參考下圖：

圖中，_segements是當(dāng)前反序列化使用過的char[]列表，currentSegement是當(dāng)前正在使用的char[]。一個char[]的大小最大為65536。在第二次反序列化大對象時至少會創(chuàng)建一個新的大小為65536的char[]（上一次的char[]是65536，再創(chuàng)建一個新char[]其大小仍不能超過65536）?？梢钥吹皆诘谝淮畏葱蛄谢Y(jié)束后和第二次反序列化結(jié)束后，雖然ThreadLocal里存放的char[]大小都是65536，但其實(shí)它們已經(jīng)不是同一個對象了。這樣的一個替換是沒有必要的，完全可以一直復(fù)用同一個char[]。

當(dāng)業(yè)務(wù)所有http接口的返回值都大且流量也大時，每次保存在ThreadLocal里的char[65536]雖然會在下次反序列化結(jié)束時被替換導(dǎo)致其失去引用，但由于其在新生代只存活了一次接口請求的時間，所以不會晉升到老年代，可以被young gc回收。但是我們項目用來處理http請求的線程池都是同一個，這些接口的返回值只有一部分超過了65536，在小于的時候ThreadLocal里的char[]不會被替換，當(dāng)這個char[]在ThreadLocal里停留一段時間后，就會晉升到老年代，從而導(dǎo)致老年代內(nèi)存增長。

（2）解決方案

關(guān)閉Jackson的USE_THREAD_LOCAL_
FOR_BUFFER_RECYCLING，關(guān)閉該開關(guān)會在每次反序列化時創(chuàng)建一個BufferRecycler，而不是復(fù)用ThreadLocal里的BufferRecycler，這樣可能導(dǎo)致young gc頻率提高。
升級Jackson版本，請參考此issue，2.17版本的jackson在調(diào)用releaseByteBuffer時會避免較小或者相同大小的char數(shù)組替換原有數(shù)組。

由于項目使用的jackson版本是2.10，直接升級到2.17的版本跨度較大，可能帶來不必要的風(fēng)險，因此采用了方案1，上線后，young gc頻率沒有明顯增加。方案2的issue里有提到使用2.16版本引入的RecyclerPool代替基于ThreadLocal的實(shí)現(xiàn)，這也是解決方案之一。

3.3 對象晉升年齡閾值過小

（1）背景知識

java對象從新生代晉升到老年代有多種原因，在本項目中，對象的主要晉升原因是在新生代長期存活，這個長期具體是多久有以下兩個判斷條件：

對象晉升年齡閾值：
可通過-XX:MaxTenuringThreshold啟動項進(jìn)行配置，對于CMS，默認(rèn)值是6。此參數(shù)定義了對象在年輕代存活的最大年齡，如果一個對象在年輕代經(jīng)過N次GC后依然存活，它將會被晉升到老年代。
動態(tài)年齡判定：
在survivor區(qū)中小于或等于某年齡的的所有對象大小的總和大于survivor空間的一定比例時，大于或等于該年齡的對象就直接進(jìn)入老年代，這個比例可以通過-XX:TargetSurvivorRatio啟動項控制，默認(rèn)值為50，代表50%。

一個對象的年齡滿足上述兩個條件之一時，就會晉升到老年代，具體的晉升年齡可以通過在啟動項里添加-XX:+PrintTenuringDistribution獲取，添加該參數(shù)后的gc日志如下圖：

其中區(qū)域2的(max 6)代表-XX:MaxTenuringThreshold啟動項配置的值，也就是說對象到達(dá)這個年齡一定會晉升，而new threshold 6代表對象實(shí)際晉升的年齡，上圖代表這次young gc因?qū)ο蟮竭_(dá)年齡閾值會導(dǎo)致9946864 bytes的對象晉升。

區(qū)域1代表動態(tài)年齡判定所需的空間大小，也就是(survivor空間大小 x targetSurvivotRatio)。此項目堆的單個survivor空間為200M，所以只要在survivor區(qū)中小于或等于某年齡的所有對象大小的總和大于200Mx50%，大于或等于該年齡的對象就會晉升。

而下圖的對象是因為動態(tài)年齡判定才晉升的，這次young gc因動態(tài)年齡判定會導(dǎo)致38660424 bytes的對象晉升：

（2）分析過程

優(yōu)化前+調(diào)參前：

在進(jìn)行dubbo和jackson以及其他業(yè)務(wù)代碼上的優(yōu)化前，我們保存了當(dāng)時的gc日志，可以看到大部分對象都是因為年齡到達(dá)6晉升的，每次young gc約有10M~16M左右的對象晉升，顯然對象的晉升年齡閾值太小，需要調(diào)大。

優(yōu)化后+調(diào)參前：

在調(diào)整 JVM 參數(shù)之前，我們決定先著手進(jìn)行業(yè)務(wù)上的優(yōu)化。因為直接進(jìn)行參數(shù)調(diào)整可能會治標(biāo)不治本，無法消除潛在的隱患。在完成業(yè)務(wù)代碼上的優(yōu)化后，可以看到此時由于年齡達(dá)到6這一閾值晉升的對象大小從最開始的10M~16M降為了4M以下，意味著在新生代長期存活的對象數(shù)量明顯減少了，但仍然有優(yōu)化空間。

（3）解決方案

在完成業(yè)務(wù)代碼上的優(yōu)化后，我們對 JVM 參數(shù)進(jìn)行了調(diào)整。將-XX:MaxTenuringThreshold參數(shù)改為15，-XX:TargetSurvivorRatio改為75%（實(shí)際上，通過調(diào)參后的gc日志我們能確定對于這個項目來說，50%也已經(jīng)夠用，因為年齡1到15的對象占用的總內(nèi)存只有38M左右，遠(yuǎn)遠(yuǎn)小于單個survivor空間的50%），以延長對象在新生代的存活時間。我們可以觀察到，盡管會有一些對象存活到年齡15的閾值才晉升，但是這部分對象的總大小變小了，大部分情況下都是小于2M。這部分對象通過添加監(jiān)控的方式判斷大概率是被移除（大小不足被淘汰，過期等原因）的caffeine本地緩存。