一次JAVA内存泄漏的定位分析过程

深藏阁楼爱情的钟 2022-05-13 22:12 244阅读 0赞

### 正式环境老是内存用完崩溃。 ###

### 在本地模拟以及解决过程 ###

### 查询JAVA线程，命令：jps -lvm ###

### ![70][] ###

### 生成dump文件：jmap -dump:live,format=b,file=aaa.hprof 22400 ###

### ![70 1][] ###

### 使用工具MAT分析： ###

### ![70 2][] ###

### 在Leak Suspects页面会给出可能的内存泄露，进入Leak Suspects，查看那些类可能发生内存泄露 ###

### ![70 3][] ###

### 发现自己写的类： ###

### ![70 4][] ###

### 线程池的问题，进入Details查看详情： ###

### 在详情页面Shortest Paths To the Accumulation Point表示GC root到内存消耗聚集点的最短路径，如果某个内存消耗聚集点有路径到达GC root，则该内存消耗聚集点不会被当做垃圾被回收。 ###

### ![70 5][] ###

### 在All Accumulated Objects by Class列举了该对象所存储的所有内容。 ###

### ![70 6][] ###

### 发现问题所在：java.util.concurrent.ThreadPoolExecutor对象占用内存太大。 ###

### 而引用这个对象的是DoctorAdviceSplitJob类，那么直接看该类代码： ###

### ![70 7][] ###

### 由于该类不是单例的（quatz的坑），每执行一次任务就会新创建一个线程池，每个线程池中创建多个线程，所以跑几次任务后，内存便被消耗完。 ###

### 解决办法：将创建线程池的代码迁移到单例类中，在job类中引用该线程池。 ###

> ## 欢迎关注公众号： ##
> 
> # ![70 8][] #

[70]: /images/20220514/3d2e31e294264eaea697b0db1d928dcd.png
[70 1]: /images/20220514/ccbf2114f32a4780a488586ec94de9a4.png
[70 2]: /images/20220514/ce5fdaf66eeb4b34884e7890994147de.png
[70 3]: /images/20220514/fb247930f8f44b70896a53a2c2d69604.png
[70 4]: /images/20220514/8dbd12de3a734ca9bc4090a27e9203cd.png
[70 5]: /images/20220514/d052e5bf9da44d7787333edcf0136e92.png
[70 6]: /images/20220514/2caf85e7196245adb620a975c6bc23d0.png
[70 7]: /images/20220514/a01d3d48b7d846f39d4b63a082062ffe.png
[70 8]: /images/20220514/473146995e8f48bdbc97b7f0a9b8e99d.png