1. 如何快速定位内存泄漏?

定位内存泄漏一般可以分三步走。

1.1 确认是否真的泄露

最简单的方式是通过如下指令确认：

jstat -gcutil pid 1000

接下来让我分析一下指令含义：

首先是jstat，它是JDK自带工具，不在系统自带命令集，必须满足两点：

a. 服务器/本机安装了JDK（不是只装JRE），配置好环境变量

b. 命令执行终端和Java进程在同一操作系统的用户下（root进程普通用户看不到，会报找不到进程）

然后就是配套参数：

• gcutil：打印GC统计百分比（使用率、回收次数、耗时），最常用的GC监控参数；
• pid：目标Java应用进程 ID；
• 1000：采样间隔，单位毫秒，每 1000ms（1 秒）输出一行数据；
• 无末尾数字 = 只输出1次，加数字 = 持续滚动输出。

直观效果：

终端会每秒刷新一行GC指标，持续打印，直到手动按Ctrl+C终止命令。 用于实时观察堆内存占用、GC 频率、STW 耗时，排查内存泄漏、频繁 FullGC、OOM 问题。

标准输出样例：

S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 22.35 45.21 18.64 92.10 88.32 123 1.456 2 0.872 2.328

字段解释：

观察GC情况：

如果老年代内存使用率一直涨，执行Full GC后也降不下来，那基本就是有内存泄漏了。或者看监控曲线，内存一直往上走，呈现锯齿状但低点越来越高，这就是典型特征。

1.2 通过dump堆快照导出对象

指令如下：

jmap -dump:live,format=b,file=heap.hprof pid

接下来让我分析一下指令含义：

首先是jmap，它是JDK自带堆快照工具，用于导出Java进程堆内存文件，以便离线分析内存泄漏、大对象、OOM。

它的使用条件同jstat一致。

-dump：

代表执行堆转储（dump堆快照），后面跟多个配置参数，用逗号分隔。

参数逐项解析：

live：

只导出当前存活对象，它会先触发一次FullGC，把已经没有引用的垃圾对象过滤掉，快照文件更小、分析更干净。

如果去掉live，就会导出全量堆，包含已死亡未回收对象，文件更大。

format=b：

固定写法，b= binary二进制格式，标准hprof二进制文件，是MAT、JProfiler、IDEA内存分析工具通用格式，不可省略。

file=heap.hprof：

指定导出的文件名heap.hprof，文件生成在当前执行命令的目录，可自定义路径，例如file=/tmp/heap_20260704.hprof。

pid：

目标 Java 进程号，可以用“ jps -l ”或者“ ps -ef | grep java ”获取。

执行后效果：

a. 程序会暂停STW（Stop-The-World），堆越大停顿越久，线上业务高峰期慎用；

b. 磁盘生成.hprof二进制堆文件；

c. 导出完成后终端输出完成提示，Java进程恢复正常运行。

如果担心OOM突然发生来不及dump，可以提前加JVM参数-XX:+HeapDumpOnOutOfMemoryError，这样OOM时会自动dump。

1.3 用MAT分析（也可选择其他内存分析工具）

用Eclipse Memory Analyzer，打开.hprof文件后它会自动给一个Leak Suspects报告，通常能直接定位问题。

如果报告不够明确，可以看Histogram视图，找到实例数量特别多或者占用内存特别大的对象，然后右键选择Path to GC Roots，选exclude weak references，这样就能看到是哪些强引用持有了这个对象导致它回收不了。

比如说你可能看到某个静态HashMap持有了这些对象，或者被ThreadLocal持有，问题就很清楚了。

1.4 总结

还有个实用技巧是对比两次堆快照。

间隔一段时间dump两次，用MAT的Compare功能对比，增长最多的对象往往就是泄漏的对象，这对缓慢泄漏的问题特别有效。

如果是本地环境调试，可以直接用JProfiler实时监控，能看到内存实时分配情况和对象引用关系，比dump快照更直观。

基本上这套流程下来，大部分内存泄漏都能定位到。

关键就是先确认有泄漏，然后dump堆快照，最后用MAT分析GC Roots引用链，找到是哪里的代码持有了不该持有的引用。

大多数遇到的内存泄漏问题，十有八九都是静态集合没清理、ThreadLocal没remove或者监听器没反注册这几种情况，看到引用链基本就能马上判断出来。