一份超实用的 OOM 内存泄露速查备忘录

公众号关注 「奇妙的 Linux 世界」

设为「星标」，每天带你玩转 Linux ！

本文整理了一份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

1. 保存线程栈：

# 保存了线程栈的现场
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分析问题，修改问题，重新发布。

本文转载自：「不焦躁的程序员」，原文：https://url.hi-linux.com/gYZYu，版权归原作者所有。欢迎投稿，投稿邮箱: editor@hi-linux.com。

最近，我们建立了一个技术交流微信群。目前群里已加入了不少行业内的大神，有兴趣的同学可以加入和我们一起交流技术，在 「奇妙的 Linux 世界」 公众号直接回复 「加群」 邀请你入群。

你可能还喜欢

点击下方图片即可阅读

如何优雅的终止 Docker 容器


点击上方图片，『美团|饿了么』外卖红包天天免费领

更多有趣的互联网新鲜事，关注「奇妙的互联网」视频号全了解！