OOM内存泄露速查备忘录
本文整理了一份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.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、分析内存
- 用MAT工具打开dump文件
- 一般打开Histogram视图,这样能快速地发现问题,也可以打开Leak Suspects(泄露嫌疑),如下图:
寻找这个对象被哪些地方引用了,如下图:
查看大对象,找出自己业务相关的关键引用:
根据上面GC Roots的结果,在结合自身的业务代码排查下,一般都会找到线索,比如:
- 某个线程远程调用了接口返回的对象,一直被使用未能释放
- 每次执行的数据量过大
- 流没有关闭
- 死循环 或者 递归次数太多
- 定时任务执行频率过高,在任务没执行完毕时又在持续执行,导致积压了大量对象
- ......
4、总结
本文整理了一份OOM内存泄露问题速查备忘录。核心内容是:
- top、free、df三连,然后netstat、jstat工具跟上。
- 紧接着赶紧jmap、jstack保存现场,然后重启应用。
- MAT分析问题,修改问题,重新发布。
本篇完结!感谢你的阅读,欢迎点赞 关注 收藏 私信!!!
原文链接:http://www.mangod.top/articles/2023/10/09/1696840322478.html、https://mp.weixin.qq.com/s/G6QEHNK4oLcPmnWgSvWfnQ