Jvm中old過高如何排查

這篇文章主要為大家展示了“Jvm中old過高如何排查”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“Jvm中old過高如何排查”這篇文章吧。

前言

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

收到了監控系統的報警，在服務器上查詢jvm內存情況

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

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文件的過程就不贅述了，簡單貼一下命令

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

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

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[]的實例信息，從大到小的排列

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

查看最大的這些實例，發現這些實例里面的內容是

<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區過高，這里就是是分享下，排查的過程，不對原因過于詳細的表述了

以上是“Jvm中old過高如何排查”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！