快捷導(dǎo)航

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

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

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

背景

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

臨時解決辦法

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

但沒過多久，上游調(diào)用方的同學又找來了，反饋當前服務(wù)又不可用了，果然該來的總是會來；

現(xiàn)象

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

gc日志顯示，當前java服務(wù)在頻繁的進行FullGC；

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

細細想來，F(xiàn)ullGC的原因無非那么幾種：

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

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

其實到這里就很明了了，元數(shù)據(jù)區(qū)內(nèi)存使用率97.26%，上次GC原因為：Metadata GC Threshold，當前GC原因為：Last ditch collection；

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

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

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