前言

最近遇到一個Jvm old過高的案例，現(xiàn)象是一個站點的jvm old區(qū)過高，分析原因是，原來的設(shè)計方案有問題，給前端返回的數(shù)據(jù)里面包含了大量的html代碼，從存儲中拿數(shù)據(jù)的過程、拼接數(shù)據(jù)的過程過于漫長了，造成了大量對象的生命周期過長，對象被 標(biāo)記到了old中，造成了old區(qū)過高，監(jiān)控系統(tǒng)進行了報警，詳細原因就不做詳細分析了，主要分享一下問題排查的過程。

收到了監(jiān)控系統(tǒng)的報警，在服務(wù)器上查詢jvm內(nèi)存情況

jstat -gcutil pid 時間間隔，可以按時間間隔打印jvm的內(nèi)存情況,例如：

jstat -gcutil 30922 1000

jvm進程30922的內(nèi)存情況

大致說一下，S0,S1這些的含義:

S0：年輕代中第一個survivor（幸存區(qū)）已使用的占當(dāng)前容量百分比
S1：年輕代中第二個survivor（幸存區(qū)）已使用的占當(dāng)前容量百分比
E： 年輕代中Eden（伊甸園）已使用的占當(dāng)前容量百分比
O： old代已使用的占當(dāng)前容量百分比
P： perm代已使用的占當(dāng)前容量百分比
YGC： 從應(yīng)用程序啟動到采樣時年輕代中g(shù)c次數(shù)
YGCT：從應(yīng)用程序啟動到采樣時年輕代中g(shù)c所用時間(s)
FGC： 從應(yīng)用程序啟動到采樣時old代(全gc)gc次數(shù)
FGCT：從應(yīng)用程序啟動到采樣時old代(全gc)gc所用時間(s)
GCT： 從應(yīng)用程序啟動到采樣時gc用的總時間(s)

從內(nèi)存情況，來看，S0、伊甸園已經(jīng)被打滿，old已經(jīng)被打滿，排除了是大對象實例過多直接把old打滿的情況，繼續(xù)分析

查看應(yīng)用啟動的jvm參數(shù)

-Xms2g -Xmx2g -Xmn1g -Xss1024K -XX:PermSize=256m -XX:MaxPermSize=512m -XX:ParallelGCThreads=8 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:SurvivorRatio=4 -XX:MaxTenuringThreshold=10 -XX:CMSInitiatingOccupancyFraction=80

說兩個參數(shù)的含義吧

XX:SurvivorRatio=4，這個參數(shù)的意思是Survivor兩個區(qū)與新生代的比例，設(shè)置為4的意思是兩個區(qū)與新生代的比例為2:4，MaxTenuringThreshold=10, 這個參數(shù)的意思是對象標(biāo)記多少次后記為old對象，放入到老年代中，設(shè)置為10就是新生代對象被標(biāo)記10次還沒有釋放，就放到老年代中，從參數(shù)上看，造成old區(qū)過高報警的原因是有的對象在新生代中，被標(biāo)記了10次都沒有被釋放，被放入到了老年代中，造成了老年代過大，F(xiàn)GC頻率過高

經(jīng)朋友指點，這一塊的分析有問題，有問題的分析留著，再貼一下朋友的分析，對比一下

動態(tài)對象年齡判定:為了能更好地適應(yīng)不同程度的內(nèi)存狀況,虛擬機并不是永遠地要求對象的年齡必須達到了MaxTenuringThreshold才能晉升到老年代,如果在Survivor空間中相同年齡的所有對象大小的總和大于Survivor空間的一半,年齡大于或等于年齡的對象就可以直接進入老年代,無須等到MaxTenuringThreshold中要求的年齡

朋友的指導(dǎo)

導(dǎo)出dump文件，使用jvisualvm.exe查看

導(dǎo)出dump文件的過程就不贅述了，簡單貼一下命令

jmap -dump:format=b,file=serviceDump.dat pid

jvisualvm是一個jdk自帶的內(nèi)存分析工具，一般位置在jdk安裝目錄下：

C:\Program Files\Java\jdk1.8.0_141\bin\jvisualvm.exe

jvisualvm工具界面

在這選擇已經(jīng)導(dǎo)出的dump文件，查看內(nèi)存中類的實例數(shù)、實例大小

查看類的實例數(shù)

發(fā)現(xiàn)是Char[],String,HashMap這三個的實例是jvm中最多的，實例數(shù)分別占31%、30.9%、30.2%，總共占了92.1%，實例的大小分別占35.8%、14.6%、22.4%，總共占了72.8%，主要是這三個類的實例占用過大的內(nèi)存

查看Char[]的實例信息

點擊去，查看Char[]的實例信息，從大到小的排列

有一些實例比別的實例大很多

查看最大的這些實例，發(fā)現(xiàn)這些實例里面的內(nèi)容是

<graph lineThickness='3' showValues='0' formatNumberScale='1' anchorRadius='3' divLineAlpha='20' divLineColor='CC3300' divLineIsDashed='1' showAlternateHGridColor='1' alternateHGridAlpha='5' alternateHGridColor='CC3300' shaowAlpha='40d' chartRightMargin='3..

目測這些都是前端使用的圖表所用到的數(shù)據(jù)，設(shè)計不合理，這些圖表的html代碼由后臺代碼給前端返回了

實例里面的內(nèi)容

查看這些實例的堆棧信息

查看這些實例的垃圾回收根節(jié)點

查看這些實例的垃圾回收根節(jié)點

發(fā)現(xiàn)是根節(jié)點是 StringBuilder對象，查看堆棧信息

查看堆棧信息

堆棧信息

通過堆棧信息，就定位到了代碼中，分析代碼，原因基本是，原來的設(shè)計方案有問題，給前端返回的數(shù)據(jù)里面包含了大量的html代碼，從存儲中拿數(shù)據(jù)的過程、拼接數(shù)據(jù)的過程過于漫長了，造成了大量對象的生命周期過長，對象被 標(biāo)記到了old中，造成了old區(qū)過高，這里就是是分享下，排查的過程，不對原因過于詳細的表述了

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。

最新評論