[GC调优]一次内存泄漏的经历分享

背景

运维人员在生产服务器上用定时任务隔一段时间生成GC文件，今天在开发群里由报警机器人发送了一条消息"xxx应用发现GC文件，下载地址:xxxx",然后总监亲自给我们展示了如何去分析GC文件来判断是否有内存泄漏。

dump二进制文件-hprof

关于如何生成hprof文件，可以详细查阅一下jmap指令.
我这里直接贴出JVM指令:

# 使用jps查看进程号,也就是pid
$> jps
# 使用jmap导出dump文件  
$> jmap -dump:format=b,file=mydump.hprof pid  

dump

MemoryAnalyzer

使用大名鼎鼎的"MAT"(Memory Analyzer Tool)可以很好的分析dump文件.
下载地址: 官网

配置堆栈大小-MemoryAnalyzer.ini

-startup
plugins/org.eclipse.equinox.launcher_1.5.0.v20180512-1130.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.700.v20180518-1200
-vmargs
-Xmx4096m

打开dump文件-open file

• 打开dump文件

open-dump

点击finish即可

finish

擒贼先擒王-Leak Suspects

Leak Suspects

看到Leak Suspects一开始我还有点懵逼，为此我还专门去查了一下google.

leak suspects

ok,这里我们看到，MAT把泄漏嫌疑最大的几个case展示出来了，那么我们可以从最大的嫌疑犯开始，直接看Problem Suspect 1.

1

• 查看内存分配树、Thread Stack

button

• 内存分配树

tree

这里说一下: 如果怀疑是SQL的问题，可以在堆栈中找找这个包所绑定的SQL:
org.apache.ibatis.mapping.BoundSql.

• Thread OverView

details

这里提供一个快速查找的技巧，一般公司的项目，都会有特定的包路径，直接ctrl+F查找相关关键字即可，比如百度的项目，直接搜索"baidu".

结果

最后，我们定位到了一个SQL未进行分页，造成了内存泄漏。这里不对结果进行展示了.