前言
最近遇到一個jvm old過高的案例，現象是一個站點的jvm old區過高，分析原因是，原來的設計方案有問題，給前端返回的數據里面包含了大量的html代碼，從存儲中拿數據的過程、拼接數據的過程過于漫長了，造成了大量對象的生命周期過長，對象被 標記到了old中，造成了old區過高，監控系統進行了報警，詳細原因就不做詳細分析了，主要分享一下問題排查的過程。
收到了監控系統的報警，在服務器上查詢jvm內存情況
jstat -gcutil pid 時間間隔，可以按時間間隔打印jvm的內存情況,例如：
|
1
|
jstat -gcutil 30922 1000 |
jvm進程30922的內存情況
大致說一下，s0,s1這些的含義:
s0：年輕代中第一個survivor（幸存區）已使用的占當前容量百分比
s1：年輕代中第二個survivor（幸存區）已使用的占當前容量百分比
e： 年輕代中eden（伊甸園）已使用的占當前容量百分比
o： old代已使用的占當前容量百分比
p： perm代已使用的占當前容量百分比
ygc： 從應用程序啟動到采樣時年輕代中gc次數
ygct：從應用程序啟動到采樣時年輕代中gc所用時間(s)
fgc： 從應用程序啟動到采樣時old代(全gc)gc次數
fgct：從應用程序啟動到采樣時old代(全gc)gc所用時間(s)
gct： 從應用程序啟動到采樣時gc用的總時間(s)
從內存情況，來看，s0、伊甸園已經被打滿，old已經被打滿，排除了是大對象實例過多直接把old打滿的情況，繼續分析
查看應用啟動的jvm參數
-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
說兩個參數的含義吧
xx:survivorratio=4，這個參數的意思是survivor兩個區與新生代的比例，設置為4的意思是兩個區與新生代的比例為2:4，maxtenuringthreshold=10, 這個參數的意思是對象標記多少次后記為old對象，放入到老年代中，設置為10就是新生代對象被標記10次還沒有釋放，就放到老年代中，從參數上看，造成old區過高報警的原因是有的對象在新生代中，被標記了10次都沒有被釋放，被放入到了老年代中，造成了老年代過大，fgc頻率過高
經朋友指點，這一塊的分析有問題，有問題的分析留著，再貼一下朋友的分析，對比一下
動態對象年齡判定:為了能更好地適應不同程度的內存狀況,虛擬機并不是永遠地要求對象的年齡必須達到了maxtenuringthreshold才能晉升到老年代,如果在survivor空間中相同年齡的所有對象大小的總和大于survivor空間的一半,年齡大于或等于年齡的對象就可以直接進入老年代,無須等到maxtenuringthreshold中要求的年齡
朋友的指導
導出dump文件，使用jvisualvm.exe查看
導出dump文件的過程就不贅述了，簡單貼一下命令
|
1
|
jmap -dump:format=b,file=servicedump.dat pid |
jvisualvm是一個jdk自帶的內存分析工具，一般位置在jdk安裝目錄下：
|
1
|
c:\program files\java\jdk1.8.0_141\bin\jvisualvm.exe |
jvisualvm工具界面
在這選擇已經導出的dump文件，查看內存中類的實例數、實例大小
查看類的實例數
發現是char[],string,hashmap這三個的實例是jvm中最多的，實例數分別占31%、30.9%、30.2%，總共占了92.1%，實例的大小分別占35.8%、14.6%、22.4%，總共占了72.8%，主要是這三個類的實例占用過大的內存
查看char[]的實例信息
點擊去，查看char[]的實例信息，從大到小的排列
有一些實例比別的實例大很多
查看最大的這些實例，發現這些實例里面的內容是
|
1
|
<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.. |
目測這些都是前端使用的圖表所用到的數據，設計不合理，這些圖表的html代碼由后臺代碼給前端返回了
實例里面的內容
查看這些實例的堆棧信息
查看這些實例的垃圾回收根節點
查看這些實例的垃圾回收根節點
發現是根節點是 stringbuilder對象，查看堆棧信息
查看堆棧信息
堆棧信息
通過堆棧信息，就定位到了代碼中，分析代碼，原因基本是，原來的設計方案有問題，給前端返回的數據里面包含了大量的html代碼，從存儲中拿數據的過程、拼接數據的過程過于漫長了，造成了大量對象的生命周期過長，對象被 標記到了old中，造成了old區過高，這里就是是分享下，排查的過程，不對原因過于詳細的表述了
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。
原文鏈接：https://www.jianshu.com/p/f04c04ed462f
