AI 排查 Java 内存泄漏：从 OOM 现场到可复现的定位流程

线上服务半夜报出 OutOfMemoryError，重启后暂时恢复，过几天又在高峰期倒下。这种反复往往不是一次性的内存不足，而是某个对象被长期持有、迟迟得不到回收。排查的关键不是立刻加大堆内存，而是把现场留下来，再用一条可复现的链路把泄漏点钉住。AI 最适合做的，是帮你读堆转储、比对增长趋势、生成最小复现代码，而不是直接替你下结论。

一、先留现场：不要只重启

OOM 发生后，第一件事是保留证据。生产 JVM 建议常驻开启堆转储参数，异常时自动生成文件，而不是事后靠猜测重建现场：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/app/heap.hprof

同时记录异常类型是 Java heap space 还是 Metaspace、GC 日志里老年代是否持续爬升、最近一次发布或流量变化。把这三类信息原样交给 AI，比只贴一段报错堆栈有用得多，它可以先帮你区分：是内存泄漏、缓存无上限增长，还是单纯堆设得太小。

二、用增长趋势缩小范围

拿到堆转储后，不要一上来就看最大的单个对象。更有效的顺序是：先看支配树中增长最快的类，再看它的引用链。把两次堆转储的类直方图交给 AI 做差分，它能快速指出哪些类的实例数和占用字节在持续增加。

接下来要人工确认两点：这些对象是谁创建的，引用链上是否有静态集合、监听器未注销、线程局部变量未清理。AI 的引用链解读需要逐条核对，它可能把中间某个框架类误认作泄漏源头。真正的泄漏点，通常是业务代码里那个只进不出的集合。

三、写一个可运行的最小复现

定位到嫌疑代码后，用一个独立小程序复现它。下面这段代码模拟了最常见的泄漏模式：静态集合不断接收新对象，却从不清理：

import java.util.ArrayList;
import java.util.List;

public class LeakDemo {
    private static final List<byte[]> CACHE = new ArrayList<>();

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < 200000; i++) {
            CACHE.add(new byte[1024]);
            if (i % 20000 == 0) {
                System.out.println("added=" + i + " size=" + CACHE.size());
                Thread.sleep(100);
            }
        }
        System.out.println("done, cache size=" + CACHE.size());
    }
}

用较小的堆运行它，例如 java -Xmx64m LeakDemo，可以在可控条件下观察内存持续上升直至 OOM。把复现交给 AI，让它给出修复方向：给缓存加容量上限、改用带过期时间的缓存，或在对象生命周期结束时显式清理。再把修复后的版本跑同一组参数，对比内存曲线是否平稳，这一步不能省。

四、修复时优先改所有权，而不是加内存

常见修复有三类：给缓存设上限和过期策略，避免无界增长；清理监听器和线程局部变量，在组件销毁时注销；收紧对象生命周期，不把请求级对象挂到静态变量或长生命周期的单例上。加大堆内存只能推迟 OOM，不能解决泄漏。如果修复后老年代曲线仍然单调上升，说明泄漏点还没找对，需要回到堆转储重新做差分。

五、把 AI 放进日常流程

更省力的做法，是把 AI 排查变成日常习惯。开发阶段让 AI 检查新增的静态集合和缓存，提醒缺少清理逻辑的地方；发布后定期用 AI 对比堆转储和 GC 日志，把增长异常提前暴露出来。华为云的 MaaS 大模型服务和 AI DevSpace 可以用来快速跑通复现代码、分析堆转储摘要，但最终的修复和上线验证，仍要由开发者在自己的服务里完成。

结语

排查 Java 内存泄漏的顺序应该是：留现场、看趋势、找引用链、做最小复现、再修复验证。AI 能帮你把海量堆信息翻译成可读线索，也能帮你写出复现代码和修复草案，但它不能代替你确认引用链和验证修复效果。把 AI 当作排查助手，而不是结论来源，OOM 就不再是只能靠重启续命的玄学问题。