最近有一個java服務的堆內存溢出，然后僵死了，在重啟服務之前用jmap命令生成了一份dump文件便于后面分析。
生成dump文件的命令：
jmap -dump:format=b,file=20170307.dump 16048
file后面的是自定義的文件名，最后的數字是進程的pid。
查看整個JVM內存狀態 jmap -heap [pid]要注意的是在使用CMS GC 情況下，jmap -heap的執行有可能會導致JAVA 進程掛起 查看JVM堆中對象詳細占用情況jmap -histo [pid] 導出整個JVM 中內存信息jmap -dump:format=b,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文件中的實例列表其實是反映了使用的堆的情況，而使用的堆內存并沒有達到預先設置的最大堆內存，只是在申請堆內存的過程中超出了預先設置的最大堆內存，然后內存溢出。
