背景
运维人员在生产服务器上用定时任务隔一段时间生成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未进行分页，造成了内存泄漏。这里不对结果进行展示了.
网友评论