快捷導(dǎo)航

測(cè)試環(huán)境頻繁Full GC問(wèn)題的解決思路分析

更新時(shí)間：2025年01月03日 08:43:22 作者：萊特昂

全文介紹了作者通過(guò)與調(diào)用方交互,發(fā)現(xiàn)welink-front服務(wù)不可用的問(wèn)題,通過(guò)jmap-heap和jstat-gccause命令,作者找到了問(wèn)題的原因是元數(shù)據(jù)區(qū)內(nèi)存使用率過(guò)高,觸發(fā)了FullGC,作者通過(guò)分析GC日志和堆內(nèi)存使用情況,確定了問(wèn)題的根本原因

背景

上游調(diào)用方，反饋當(dāng)前welink-front服務(wù)不可用；

臨時(shí)解決辦法

手動(dòng)重啟welink-front服務(wù)，重啟之后觀測(cè)到業(yè)務(wù)日志正常刷，說(shuō)明該問(wèn)題暫時(shí)得到了解決；

但沒(méi)過(guò)多久，上游調(diào)用方的同學(xué)又找來(lái)了，反饋當(dāng)前服務(wù)又不可用了，果然該來(lái)的總是會(huì)來(lái)；

現(xiàn)象

直接jmap -heap [pid]打印堆內(nèi)存大小，瞧著內(nèi)存使用情況挺正常的；

gc日志顯示，當(dāng)前java服務(wù)在頻繁的進(jìn)行FullGC；

這里有個(gè)點(diǎn)，就是FullGC后，堆可用內(nèi)存大小基本沒(méi)怎么變化，GC了個(gè)寂寞；

細(xì)細(xì)想來(lái)，F(xiàn)ullGC的原因無(wú)非那么幾種：

1、實(shí)際業(yè)務(wù)導(dǎo)致堆內(nèi)存短時(shí)間內(nèi)暴增，例如高并發(fā)場(chǎng)景；
2、大對(duì)象；
3、內(nèi)存泄漏，老年代存在大量釋放不掉的對(duì)象；
4、元數(shù)據(jù)區(qū)滿了；
5、堆外內(nèi)存；
6、System.gc();

其實(shí)糾結(jié)那么多干嘛，直接jstat -gccause [pid]看GC原因就好了；

其實(shí)到這里就很明了了，元數(shù)據(jù)區(qū)內(nèi)存使用率97.26%，上次GC原因?yàn)椋篗etadata GC Threshold，當(dāng)前GC原因?yàn)椋篖ast ditch collection；

Metadata GC Threshold：metaspace空間不能滿足分配時(shí)觸發(fā)，這個(gè)階段不會(huì)清理軟引用；
Last ditch collection：經(jīng)過(guò)Metadata GC Threshold觸發(fā)的full gc后還是不能滿足條件，這個(gè)時(shí)候會(huì)觸發(fā)再一次的gc cause為L(zhǎng)ast ditch collection的full gc，這次full gc會(huì)清理掉軟引用；

到這里基本可以斷定，就是元數(shù)據(jù)區(qū)內(nèi)存不夠霍霍了；根據(jù)前面堆內(nèi)存打印顯示，元數(shù)據(jù)區(qū)內(nèi)最大為128M；這個(gè)也跟前面GC日志的結(jié)果相吻合；

所以解決方案就是直接調(diào)大堆內(nèi)存和元數(shù)據(jù)區(qū)內(nèi)存；