最近遇到一個Jvm old過高的案例，現(xiàn)象是一個站點的jvm old區(qū)過高，分析原因是，原來的設(shè)計方案有問題空郊，給前端返回的數(shù)據(jù)里面包含了大量的html代碼，從存儲中拿數(shù)據(jù)的過程切揭、拼接數(shù)據(jù)的過程過于漫長了狞甚，造成了大量對象的生命周期過長，對象被 標(biāo)記到了old中廓旬，造成了old區(qū)過高哼审，監(jiān)控系統(tǒng)進(jìn)行了報警，詳細(xì)原因就不做詳細(xì)分析了孕豹，主要分享一下問題排查的過程涩盾。
收到了監(jiān)控系統(tǒng)的報警，在服務(wù)器上查詢jvm內(nèi)存情況
jstat -gcutil pid 時間間隔励背，可以按時間間隔打印jvm的內(nèi)存情況,例如：
jstat -gcutil 30922 1000
大致說一下春霍，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)存狀況,虛擬機(jī)并不是永遠(yuǎn)地要求對象的年齡必須達(dá)到了MaxTenuringThreshold才能晉升到老年代,如果在Survivor空間中相同年齡的所有對象大小的總和大于Survivor空間的一半,年齡大于或等于年齡的對象就可以直接進(jìn)入老年代,無須等到MaxTenuringThreshold中要求的年齡
導(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
在這選擇已經(jīng)導(dǎo)出的dump文件，查看內(nèi)存中類的實例數(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代碼由后臺代碼給前端返回了
查看這些實例的堆棧信息
查看這些實例的垃圾回收根節(jié)點
發(fā)現(xiàn)是根節(jié)點是 StringBuilder對象条辟，查看堆棧信息
通過堆棧信息，就定位到了代碼中宏胯，分析代碼羽嫡，原因基本是，原來的設(shè)計方案有問題肩袍，給前端返回的數(shù)據(jù)里面包含了大量的html代碼杭棵，從存儲中拿數(shù)據(jù)的過程、拼接數(shù)據(jù)的過程過于漫長了氛赐，造成了大量對象的生命周期過長魂爪，對象被 標(biāo)記到了old中，造成了old區(qū)過高艰管，這里就是是分享下滓侍，排查的過程，不對原因過于詳細(xì)的表述了
這次排查問題的過程就為大家分享到這里牲芋，歡迎大家來交流撩笆，指出文中一些說錯的地方尔破，讓我加深認(rèn)識，愿大家沒有bug浇衬，謝謝懒构！
