前言

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

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

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

jstat -gcutil 30922 1000

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

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

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

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

查看應(yīng)用啟動(dò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

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

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

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

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

朋友的指導(dǎo)

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

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

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

jvisualvm是一個(gè)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ù)、實(shí)例大小

查看類的實(shí)例數(shù)

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

查看Char[]的實(shí)例信息

點(diǎn)擊去，查看Char[]的實(shí)例信息，從大到小的排列

有一些實(shí)例比別的實(shí)例大很多

查看最大的這些實(shí)例，發(fā)現(xiàn)這些實(shí)例里面的內(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..

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

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

查看這些實(shí)例的堆棧信息

查看這些實(shí)例的垃圾回收根節(jié)點(diǎn)

查看這些實(shí)例的垃圾回收根節(jié)點(diǎn)

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

查看堆棧信息

堆棧信息

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

總結(jié)

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