OOM内存泄露速查备忘录

本文整理了一份OOM内存泄露问题速查备忘录,详细见下文。

1、核心步骤

  1. top、free、df三连,查看CPU、内存、磁盘的大致情况。
  2. netstat -lp 查看端口占用情况。
  3. 导出内存dump文件:
ini 复制代码
# 保存了堆内存现场 
jmap -dump:format=b,file=heap.dump pid
# 强制保存了堆内存现场
jmap -F -dump:format=b,file=heap.dump pid
  1. 保存线程栈:
bash 复制代码
# 保存了线程栈的现场
jstack pid > jstack.log

2、辅助工具

  • jstat -gc[gcutil] pid [interval]查看JVM垃圾回收情况。通过 jstat 查看 GC 信息,首先就是判断 GC 时间是否较长,GC 发生是否频繁,然后看是否经常性进行 FullGC。
yaml 复制代码
# 如: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分析问题,修改问题,重新发布。

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

原文链接: www.mangod.top/articles/20...mp.weixin.qq.com/s/G6QEHNK4o...

相关推荐
IT_陈寒9 分钟前
Python 3.12 的7个性能优化技巧,让你的代码快如闪电!
前端·人工智能·后端
boy快快长大14 分钟前
使用LoadBalancer替换Ribbon(五)
后端·spring cloud·ribbon
绝无仅有26 分钟前
Go 面试题:Goroutine 和 GMP 模型解析
后端·面试·github
风象南31 分钟前
SpringBoot 集成 Linux Watchdog:从应用层到系统级的自愈方案
后端
zzywxc78731 分钟前
苹果WWDC25开发秘鉴:AI、空间计算与Swift 6的融合之道
java·人工智能·python·spring cloud·dubbo·swift·空间计算
拾光师1 小时前
flume接收处理器:构建高可用与高性能的数据链路
后端
Victor3561 小时前
Redis(39)如何添加和移除Redis集群中的节点?
后端
Victor3562 小时前
Redis(38)Redis集群如何实现故障转移?
后端
hqxstudying2 小时前
Java类加载机制
java·开发语言
羑悻的小杀马特2 小时前
【Linux篇章】再续传输层协议UDP :从低可靠到极速传输的协议重生之路,揭秘无连接通信的二次进化密码!
linux·运维·服务器·后端·网络协议·udp