記一次不太成功的頻繁 full gc 排查過程

上周自己負(fù)責(zé)的一個應(yīng)用出現(xiàn)頻繁full gc的問題，不得不嘗試優(yōu)化一下。第一次做這種事只能先看看網(wǎng)上的文章，然后親自嘗試怎么去完成減少full gc的頻率，降低young gc的頻率這一目標(biāo)。雖然最終只是勉強(qiáng)解決了，但還是希望記錄下來給下一次積攢經(jīng)驗(yàn)。

選取了上周優(yōu)化前后的兩個典型工作日上午9:00到晚上9:00的GC情況。優(yōu)化前一天要發(fā)生高達(dá)上10次的full gc，young gc也非常頻繁。優(yōu)化后的圖已經(jīng)沒有出現(xiàn)full gc，young gc的頻率也大大降低了，所以說基本完成目標(biāo)。

接下來說明排查過程

1.jps命令查看進(jìn)程id

jps是java后自帶的查看虛擬機(jī)進(jìn)程狀態(tài)命令工具，用如下命令就可以看到虛擬機(jī)執(zhí)行主類和進(jìn)程ID.
jps -l




2. jmap命令導(dǎo)出堆轉(zhuǎn)儲文件

jmap是java自帶的內(nèi)存映像工具，能將當(dāng)前應(yīng)用運(yùn)行內(nèi)存的情況導(dǎo)出為文件。注意格式，file后面是導(dǎo)出路徑，最后的數(shù)字為上一步得到的進(jìn)程id。一般導(dǎo)出來的文件都比較大，我導(dǎo)出的有2.1G，而且進(jìn)行分析也很耗性能，所以導(dǎo)出后都要傳輸?shù)狡渌鼨C(jī)器上進(jìn)行分析，并且為了避免占用磁盤空間刪除本地文件。
jmap -dump:format=b,file=kfwebHeap1016.hprof 35073




3.mat工具分析堆轉(zhuǎn)儲文件

mat是eclipse提供的堆轉(zhuǎn)儲文件分析工具，用mat打開mat上一步導(dǎo)出的文件，如下圖所示，可以看到總體內(nèi)存占用情況的扇形圖，哪個文件占用內(nèi)存最多就可以一目了然了。

點(diǎn)擊histogram就可以看出各個對象的內(nèi)存占用情況，如下所示

點(diǎn)擊Leak Suspects就可以給出最有可能發(fā)生內(nèi)存泄漏的幾種情況。能很好的幫助用戶進(jìn)行內(nèi)存分析，這也是mat強(qiáng)大的重要體現(xiàn)，如下：

到這里應(yīng)該是最關(guān)鍵的環(huán)節(jié)了，可能因?yàn)闆]有經(jīng)驗(yàn)，看來看去也沒看出哪里不對，所以只能作罷，這條路已經(jīng)走不下去了，所以說這次分析不太成功。

4.G1來了

后來向一個老同事說明了我的情況，他問我用的什么垃圾回收器，我說用的是默認(rèn)的，年經(jīng)代用Parallel Scavenge，老年代用Parallel Old，他說讓我先換到G1試試吧。然后我查了一下，發(fā)現(xiàn)G1果然比較牛逼，雖然保留了以前的新生代Eden，Survivor和老年代的概念，但新生代和老年代不再物理隔離，而且它將內(nèi)存分為很多等大的region，每個region根據(jù)需要都有可能成為S(Surviror),E(Eden), O(Old)的一種，所以G1既能回收新生代也能回收老年代，它以垃圾回收為第一（這也是它名字的由來:Garbage First，G1）目標(biāo)，勵志于取決CMS, 并且在java9是已經(jīng)是jdk默認(rèn)的垃圾回收器了。說了這么多，暫時(shí)沒有多時(shí)間深入研究，不管怎么樣還是值得一試的。于是在應(yīng)用的jvm啟動參數(shù)加了如下一行:
-XX:+UseG1GC
當(dāng)然只是在一臺機(jī)器上作了處理，也便于與其它機(jī)器作對比。

5.MetaSpace調(diào)整

通過調(diào)整后的這臺機(jī)器與其它機(jī)器對比，gc情況還是改善了不少，但是在查看gc日志時(shí)發(fā)現(xiàn)了這么這個頻繁出現(xiàn)的問題：
Metadata GC Threshold
由于元數(shù)據(jù)空間不足導(dǎo)致的GC.原來在G1中設(shè)置PermSize(永久代大小)已經(jīng)沒用了，取而代之的是MetaSpace參數(shù)，雖然這個用的是并非堆內(nèi)存而是機(jī)器的物理內(nèi)存并且最大大小沒有限制，但是默認(rèn)初始大小只有20m，所以要作出調(diào)整：
-XX:MetaspaceSize=128m
加了之后果然就沒有出現(xiàn)這個問題了

6. 解決Humongous Allocation

在gc日志中還發(fā)現(xiàn)頻繁出現(xiàn)：
G1 Humongous Allocation
這個是由于大型對象分配導(dǎo)致的問題，大型(Humongous)對象是指超過G1的Region 50%的內(nèi)存對象，頻繁大型對象內(nèi)存內(nèi)存分配會導(dǎo)致性能問題，而且如果一個region中大型對象過多的話則最后一個大型對內(nèi)象邊界和該region的邊界之間的空間將不會被使用，如果有多個這樣的region將會導(dǎo)致堆內(nèi)存的碎片化，在jdk1.8u40之前這些大型對象的清理在full gc期間進(jìn)行完成。較新的jvm也是把大型對象放在清理階段，要解決上面的問題有兩種方法。
1.增加region的大小(注意要在1到32m之間并且為2的整數(shù)次冪)
2.增加堆內(nèi)存大小

總結(jié)：其實(shí)這一次只是引進(jìn)了G1垃圾回收器并且對相關(guān)參數(shù)進(jìn)行調(diào)整，但是促使我去了解jvm相關(guān)的知識和工具使用，還是有很很大收獲的

作者：Acamy
鏈接：https://www.jianshu.com/p/900d7376b8b1

—————END—————

更多精彩：
Java實(shí)戰(zhàn)項(xiàng)目視頻，給需要的讀者，收藏！
SpringBoot 如何上傳大文件？
微信支付的軟件架構(gòu)到底有多牛？
Java常用的幾個Json庫，性能強(qiáng)勢對比！
求求你們了，別再寫滿屏的 if/ else 了！
基于Spring+SpringMVC+Mybatis的分布式敏捷開發(fā)系統(tǒng)架構(gòu)（附源碼）

關(guān)注公眾號，查看更多優(yōu)質(zhì)文章

最近，整理一份Java資料《Java從0到1》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：關(guān)注公眾號并回復(fù)?Java?領(lǐng)取，更多Java內(nèi)容陸續(xù)奉上。
明天見(??ω??)??