本文整理了一份OOM內存泄露問題速查備忘錄，詳細見下文。

1、核心步驟

1. top、free、df三連，查看CPU、內存、磁盤的大致情況。
2. netstat -lp 查看端口占用情況。
3. 導出內存dump文件：

# 保存了堆內存現場 
jmap -dump:format=b,file=heap.dump pid
# 強制保存了堆內存現場
jmap -F -dump:format=b,file=heap.dump pid

4. 保存線程棧：

# 保存了線程棧的現場
jstack pid > jstack.log

2、輔助工具

• jstat -gc[gcutil] pid [interval]查看JVM垃圾回收情況。通過 jstat 查看 GC 信息，首先就是判斷 GC 時間是否較長，GC 發生是否頻繁，然后看是否經常性進行 FullGC。

# 如：jstat -gc pid 1000，持續跟蹤如1S一次。查看java堆的狀況，顯示具體數值。
jstat -gc pid 1000
# 通過 jstat -gcutil 5 1000命令查看GC信息，其中5代表進程號，1000代表顯示時間。查看堆中各個區域已使用空間占其總空間的百分比。
jstat -gcutil pid 1000

• 借助MAT（Eclipse Memory Analyzer）工具分析dump文件，分析內存情況。
• 直接用文本工具打開jstack文件，分析線程占用情況。
• 借助VisualVM更直觀：

3、分析過程

3.1、分析線程棧

直接通過文本工具打開jstack.log，搜索業務相關包名，應該大致能定位出問題：

3.2、分析內存

 1. 用MAT工具打開dump文件

2. 一般打開Histogram視圖，這樣能快速地發現問題，也可以打開Leak Suspects（泄露嫌疑），如下圖：

尋找這個對象被哪些地方引用了，如下圖：

查看大對象，找出自己業務相關的關鍵引用：

根據上面GC Roots的結果，在結合自身的業務代碼排查下，一般都會找到線索，比如：

• 某個線程遠程調用了接口返回的對象，一直被使用未能釋放
• 每次執行的數據量過大
• 流沒有關閉
• 死循環 或者 遞歸次數太多
• 定時任務執行頻率過高，在任務沒執行完畢時又在持續執行，導致積壓了大量對象
• ......

4、總結

本文整理了一份OOM內存泄露問題速查備忘錄。核心內容是：

• top、free、df三連，然后netstat、jstat工具跟上。
• 緊接著趕緊jmap、jstack保存現場，然后重啟應用。
• MAT分析問題，修改問題，重新發布。