公众号关注 「奇妙的 Linux 世界」
设为「星标」,每天带你玩转 Linux !
本文整理了一份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、分析内存
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 容器
点击上方图片,『美团|饿了么』外卖红包天天免费领
更多有趣的互联网新鲜事,关注「奇妙的互联网」视频号全了解!