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

1、核心步驟

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

# 保存了堆內(nèi)存現(xiàn)場 
jmap -dump:format=b,file=heap.dump pid
# 強制保存了堆內(nèi)存現(xiàn)場
jmap -F -dump:format=b,file=heap.dump pid

4. 保存線程棧：

# 保存了線程棧的現(xiàn)場
jstack pid > jstack.log

2、輔助工具

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

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

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

3、分析過程

3.1、分析線程棧

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

3.2、分析內(nèi)存

 1. 用MAT工具打開dump文件

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

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

查看大對象，找出自己業(yè)務相關(guān)的關(guān)鍵引用：

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

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

4、總結(jié)

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

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