Full GC 排查实战：MAT 定位 Java 内存泄漏

生产环境接口突然变慢、CPU 飙高，top 一看竟是 JVM 在疯狂 Full GC。Full GC 会触发 Stop-The-World，所有业务线程暂停，单次停顿几百毫秒到几秒，积累起来接口 P99 直接崩盘。很多人第一反应是”堆不够大，加内存”，但加内存往往只是把崩溃推迟几小时，因为真正的病灶是对象本该被回收却始终被引用拽着，堆越大单次回收越慢，反而雪上加霜。本文用 jstat 抓取 GC 现场，再用 MAT 打开堆转储，一步步定位 Java 内存泄漏根因，并给出可直接照做的修复清单。

一、先确认：到底是 Full GC 还是别的

不要一上来就 dump 堆。先用 jstat 看 GC 频率与耗时，确认是 Old 区回收不掉导致的 Full GC，而不是普通 Young GC 抖动或业务自身慢。拿到 PID 后持续采样：

jstat -gcutil $(pgrep -f 'your-app.jar') 1000 10
# 再配合 GC 日志，拿到带时间戳的停顿记录
java -Xlog:gc*,gc+heap=debug:file=/var/log/app/gc.log:time,uptime,level,tags -jar your-app.jar

若 O 区居高不下 + FGC 飙升，基本可以锁定是内存泄漏（对象回收不掉），而不是单纯的吞吐压力。这里要区分两种”老年代增长”：正常的缓存预热或批量任务会让 Old 区短暂升高，但随着请求结束、引用释放，它会自然回落；而泄漏的特征是只涨不跌——每次 GC 后 Old 区水位都比上一轮更高，FGC 间隔越来越短，直到频繁 Full GC 把吞吐吃光。看到”锯齿形上升”的 O 区曲线，就可以判定泄漏。此时再去抓堆，才有的放矢。

二、抓取堆现场：两种姿势

2.1 主动 jmap 抓取

# live 只 dump 存活对象，文件更小、更快
jmap -dump:live,format=b,file=/tmp/heap_$(date +%s).hprof <pid>

注意 jmap -live 本身会触发一次 Full GC 来回收死对象，对在线服务有秒级 STW；大堆（几十 GB）慎用，必要时配合 jstack 同时抓线程，看是不是线程堆积间接拖垮了内存。

2.2 OOM 自动转储（推荐常驻）

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/log/app/heap.hprof
-XX:OnOutOfMemoryError="kill -9 %p"

三、用 MAT 打开堆转储，三步走

MAT（Memory Analyzer Tool）是分析 hprof 的标配。打开后会自动给出 Leak Suspects 报告，但更可靠的是手动三步，避免被误报带偏：

• Leak Suspects Report：一键列出可疑对象与占用概览。
• Dominator Tree：支配树，看哪些对象”霸占”了最多保留堆（Retained Heap）。
• Path to GC Roots → exclude weak/soft/phantom：只看强引用链，定位谁在死死拽住大对象。

也可以直接用 OQL 捞大对象，按保留大小排序：

SELECT o, o.@retainedHeapSize
FROM java.util.HashMap o
ORDER BY o.@retainedHeapSize DESC

四、案例一：静态缓存只增不减

某接口用静态 Map 做本地缓存，computeIfAbsent 只塞不删，流量一高 Old 区很快打满，FGC 每分钟几十次：

private static final Map<String, Object> CACHE = new ConcurrentHashMap<>();

void load(String key){
    // 只增不减，key 无限膨胀 → 内存泄漏
    CACHE.computeIfAbsent(key, k -> expensiveQuery(k));
}

MAT 里 Dominator Tree 会显示这个 ConcurrentHashMap 保留了近 1.2GB，Path to GC Roots 一路指到静态字段。这种”静态集合只塞不删”是生产最常见的泄漏形态：本地缓存、会话表、去重 Set，只要用 static 修饰又没淘汰策略，流量一涨就爆。修复方法是换成有上限、有 TTL 的缓存：

// 用 Caffeine 兜底容量与过期，杜绝无限增长
LoadingCache<String, Object> CACHE = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(Duration.ofMinutes(30))
    .build(key -> expensiveQuery(key));

五、案例二：ThreadLocal 在线程池里泄漏

另一个高频雷区是 ThreadLocal 在线程池里忘了 remove。线程被池子复用，第一次写入的大对象会一直挂在那个线程上，请求越多泄漏越多：

private static final ThreadLocal<byte[]> BUF =
        ThreadLocal.withInitial(() -> new byte[1024 * 1024]);

void handle(Request req){
    BUF.get(); // 每次写入 1MB，线程池复用时永不释放
}

正确写法必须放在 try/finally 里清理，让线程归还池子前释放引用：

void handle(Request req){
    try {
        BUF.get();
        // ... 业务处理
    } finally {
        BUF.remove(); // 必须清理，否则线程池线程长期持有
    }
}

六、修复后验证

复测时同时看 jstat 与 GC 日志，对比修复前后的关键指标：

jstat -gcutil <pid> 1000
# 观察 FGC 是否停止增长，O 区是否回落到正常水位

复测后 FGC 归零、O 区稳定回落、接口 P99 恢复正常，说明泄漏已根治。上线前用 JMH 微基准 压一压，能在早期暴露 Old 区增长趋势，而不是等线上告警。

七、生产环境内存泄漏检查清单

jmap -histo:live <pid> | head -30
# 关注排在前几位的、自己包名下的类，而不是 java.lang.String 这类正常大户