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...

相关推荐
coderzpw32 分钟前
当模板方法模式遇上工厂模式:一道优雅的烹饪架构设计
java·模板方法模式
直裾36 分钟前
Mapreduce初使用
java·mapreduce
Asthenia041240 分钟前
准备面试:Jenkins部署SpringCloudAlibaba微服务商城全攻略
后端
woniu_maggie1 小时前
SAP EXCEL DOI 详解
开发语言·后端·excel
uhakadotcom1 小时前
云计算与开源工具:基础知识与实践
后端·面试·github
悠夏安末1 小时前
intellij Idea 和 dataGrip下载和安装教程
java·ide·intellij-idea
suimeng61 小时前
ChromeDriver的常用方法
java·selenium
Asthenia04121 小时前
零基础指南:在Linux上用Docker和Jenkins实现Spring Cloud微服务的CI/CD
后端
Hellyc1 小时前
SpringMVC响应数据:页面跳转与回写数据
java·前端·学习
嘵奇2 小时前
深入解析 Spring Boot 测试核心注解
java·spring boot·后端