本文整理了一份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分析问题，修改问题，重新发布。