背景

上游調(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ù)導致堆內(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)存；

為什么是直接調(diào)大元數(shù)據(jù)區(qū)的內(nèi)存大小呢?

是因為在測試環(huán)境的發(fā)布模板中，我們通常會直接將內(nèi)存調(diào)小；

反思與總結(jié)

測試環(huán)境的問題，發(fā)現(xiàn)了應(yīng)當立即定位分析根本原因，然后評估影響并確定解決方案，不要把懸念帶上生產(chǎn)；

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論