内存泄露排查记录
Posted ncy1
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了内存泄露排查记录相关的知识,希望对你有一定的参考价值。
一 、问题定位
手段一:通过 jstat -gcutil 快速定位GC问题(首先)
命令格式: jstat -gcutil <pid> <period>
命令样例:jstat -gcutil 11900 3s
------> 监控进程11900的GC情况, 每3s输出一条记录。
要点:O列(老年代内存使用率)一直接近100%;
FG列(Full GC次数) 一直增长。
手段二:增加Xmx参数,加大堆内存排除堆内存过小因素影响。
在jstat -gcutil 的O列占满情况,需进一步排除是否是堆内存分配过小,满足不了业务请求量导致。
查看最大堆内存命令:jinfo -flag MaxHeapSize <pid> 。
假如开始是4G,修改成8G:java -Xmx8G
要点:增加最大堆内存后,使用jstat -gcutil 看O列是否满负,如果还是满负, 则可基本确定是内存泄露。
手段三:使用 jmap -histo 命令定位内存泄露具体对象。
该命令展示所有类的实例个数以及内存用量情况,并按照使用量降序输出,一般自己写的类有内存泄露,那会名列前茅。
命令1:jmap -histo <pid>
命令样例:jmap -histo 42530 | head -n 20
输出对应进程当前所有存活对象的堆内存占用情况,找到"突出" 的嫌疑类。
命令2:jmap -histo:live <pid>
带上live,会触发一次Full GC后再输出结果,实际上就是回收了无用的对象,输出真正存活的对象情况。如果嫌疑类名实例数不减,那么十有八九这个类就是导致内存泄露根因。
要点:两个命令对比观察Full GC后,实例数不减的类,重点关注排在前面的几个自己写的类名。
手段四:使用 jmap -dump:file 导出堆内存数据。
通过手段三,一般可以定位出代码位置,但代码中很多地方引用了这个类,则要导出 Dump 文件,进一步分析泄露对象的GCRoot 。
命令:jmap -dump:file=<文件名> <pid>
样例:jmap -dump:file=app.dump 9336
分析dump文件的工具:除了JDK自带的 jhat , jvisualvm ,还有第三方的MAT,jprofiler等。
内存泄露的话,dump文件也会很大,为了防止卡死,一般会将Xmx控制在一个合适的大小(2G) ,重现问题后, 再导出dump 。
要点:将Xmx设小一点,再导出dump。
手段五:jhat分析dump文件,寻找GC Root。
因为网络拷贝大容量的dump文件诸多不便,所以需要现网直接分析dump文件,jhat可以启动一个http服务,提供页面远程分析对象引用情况。
命令:jhat -J-Xmx2G -port <port> <dump文件>
样例:jhat -J-Xmx2G app.dump
其中Xmx2G代表使用2G堆内存运行jhat,下一步可浏览器分析了,URL:http://ip:7000
要点:首先链接到嫌疑类的具体某个对象页面,分析这个对象的引用情况是否正常,再通过“Reference chains from Rootset ”获取所有的GC Root ,进而定位到具体代码位置。
以上是关于内存泄露排查记录的主要内容,如果未能解决你的问题,请参考以下文章