用jvisualvm分析dump檔案

最近有一個java服務的堆記憶體溢出，然後僵死了，在重啟服務之前用jmap命令產生了一份dump檔案便於後面分析。

產生dump檔案的命令：

jmap -dump:format=b,file=20170307.dump 16048

file後面的是自訂的檔案名稱，最後的數字是進程的pid。

使用jvisualvm來分析dump檔案：

jvisualvm是JDK內建的Java效能分析工具，在JDK的bin目錄下，檔案名稱就叫jvisualvm.exe。

jvisualvm可以監控本地、遠端java進程，即時查看進程的cpu、堆、線程等參數，對java進程產生dump檔案，並對dump檔案進行分析。

像我這種從伺服器上dump下來檔案也可以直接扔給jvisualvm來分析。

使用方式：直接雙擊開啟jvisualvm.exe，點擊檔案->裝入，在檔案類型那一欄選擇堆，選擇要分析的dump檔案，開啟。

裝入之後在介面右側的概要、類等選項卡可以看到產生dump檔案當時的堆資訊：

可以看到，dump檔案裡記錄的堆中的執行個體，總大小大概300M左右，（用第一行的執行個體大小除以百分比就能算出來），和JVM預設的新生代的大小差不多，遠小於JVM中設定的最大堆記憶體，也就是說，dump檔案裡記錄的並不是執行個體大小達到最大堆記憶體時的狀態。

為了驗證一下，我自己在本地類比了一下堆記憶體溢出的情形，並用jvisualvm監控

我本地設定的最大堆記憶體是800M左右，代碼裡面是往一個List裡面瘋狂加資料，直到撐爆堆記憶體，得到的監控內容是這樣的：

分析：紅框框出的部分是發生堆記憶體溢出時的情形，已使用的堆大小（藍色部分）並沒有增長特別明顯，但是申請的堆的大小（黃色部分）從預設的400多兆急速上漲，漲到800M，然後記憶體溢出，然而使用的堆大小依然沒怎麼增長。

所以，dump檔案中的執行個體列表其實是反映了使用的堆的情況，而使用的堆記憶體並沒有達到預先設定的最大堆記憶體，只是在申請堆記憶體的過程中超出了預先設定的最大堆記憶體，然後記憶體溢出。

最後，jvisualvm確實挺好用的。