OOM内存泄露速查备忘录

  |   0 评论   |   0 浏览

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

  1. 一般打开Histogram视图,这样能快速地发现问题,也可以打开Leak Suspects(泄露嫌疑),如下图:

寻找这个对象被哪些地方引用了,如下图:

查看大对象,找出自己业务相关的关键引用:

根据上面GC Roots的结果,在结合自身的业务代码排查下,一般都会找到线索,比如:

  • 某个线程远程调用了接口返回的对象,一直被使用未能释放
  • 每次执行的数据量过大
  • 流没有关闭
  • 死循环 或者 递归次数太多
  • 定时任务执行频率过高,在任务没执行完毕时又在持续执行,导致积压了大量对象
  • ......

4、总结

本文整理了一份OOM内存泄露问题速查备忘录。核心内容是:

  • top、free、df三连,然后netstat、jstat工具跟上。
  • 紧接着赶紧jmap、jstack保存现场,然后重启应用。
  • MAT分析问题,修改问题,重新发布。

本篇完结!感谢你的阅读,欢迎点赞 关注 收藏 私信!!!

原文链接: http://www.mangod.top/articles/2023/10/09/1696840322478.htmlhttps://mp.weixin.qq.com/s/G6QEHNK4oLcPmnWgSvWfnQ


标题:OOM内存泄露速查备忘录
作者:程序员半支烟
地址:http://www.mangod.top/articles/2023/10/09/1696840322478.html