本文整理了一份OOM内存泄露问题速查备忘录，详细见下文。
1、核心步骤
- top、free、df三连，查看CPU、内存、磁盘的大致情况。
- netstat -lp 查看端口占用情况。
- 导出内存dump文件：
# 保存了堆内存现场
jmap -dump:format=b,file=heap.dump pid
# 强制保存了堆内存现场
jmap -F -dump:format=b,file=heap.dump pid- 保存线程栈：
# 保存了线程栈的现场
jstack pid > jstack.log2、辅助工具
- 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分析问题，修改问题，重新发布。
