内存泄漏排查

hxj..

已于 2024-12-07 22:42:09 修改

阅读量1.4k

点赞数 2

分类专栏： Java基础文章标签： jvm java 算法

于 2022-10-08 23:47:43 首次发布

本文链接：https://blog.csdn.net/qq_44845473/article/details/126969257

版权

Java基础专栏收录该内容

12 篇文章 0 订阅

订阅专栏

查看进程ID：
```
jps
```
例：
查看堆内存占用及GC情况，每5秒刷新一次：
```
jstat -gcutil 17488 5000
```
例：

发现问题： 老年代内存使用率一直接近100%，Full GC次数一直增长
排除堆内存过小的可能：增大Xmx参数值

查看命令行初始堆大小及最大堆大小：
```
java -XX:+PrintCommandLineFlags -version
```
例：

在/bin/catalina.sh文件下修改初始堆及最大堆大小：
```
JAVA_OPTS='-Xms4096m -Xmx4096m'
```
根据阿里规范两个参数大小最好保持一致，减少堆扩张带来的问题

最后使用 jstat -gcutil 查看老年代空间占用，如果还是满的，说明存在内存泄漏
查找内存泄漏具体对象：
```
jmap -histo 17488 
```
根据占用空间大小降序输出

例：

也可只查询前10个最大占用的对象：jmap -histo 17488 | head -n 10

回收掉无用对象，再次查看存活对象：
```
jmap -histo:live 17488 
```
该命令会执行一次GC，之后打印存活对象

例：

结果： 发现某个类对象GC前后实例数变化不大，这个应该就是内存泄漏的类了
如果代码中很多地方用到了这个类，则需要Dump转存成文件：
```
jmap  -dump:file=app.dump  17488
```
例：

也可以通过参数设置，内存溢出时自动生成dump文件：
```
‐XX:+HeapDumpOnOutOfMemoryError ‐XX:HeapDumpPath=D:jvm.dump
```
注：内存泄漏dump文件也会很大，可能卡死，可以将Xmx限制在2G，重现问题后再dump
使用jhat分析dump文件，寻找GC Root
```
jhat  -J-Xmx2G  app.dump
```
访问网址：http://localhost:7000

最后：链接到嫌疑类的具体某个对象页面，分析这个对象的引用情况是否正常，再通过“Reference chains from Rootset ”获取所有的GC Root ,进而定位到具体代码位置。

参考博客：(2条消息) 使用jstat排查内存泄漏 - CSDN