Java 内存泄漏：常见原因及检测方法

你的 Java 应用启动很快，但数小时或数天后会慢如蜗牛，抛出 OutOfMemoryError，或被容器杀死。你重启它，循环往复。这就是 Java 内存泄漏的典型特征：不再需要的对象仍然可达，垃圾收集器无法回收它们。与 C/C++ 不同，Java 的 GC 自动处理大部分内存，但当引用被无意中持有时，泄漏仍然会发生。本文解释了最常见的原因，并提供了检测和修复它们的实用工作流程。

什么是 Java 内存泄漏？

当对象不再被应用程序使用但仍被引用，阻止垃圾收集时，就会发生内存泄漏。随着时间的推移，堆使用量增长，GC 运行更频繁，最终 JVM 抛出 OutOfMemoryError: Java heap space。泄漏可能很小很慢（每个请求几 KB），也可能很大很快（缓存整个结果集）。

Java 内存泄漏的常见原因

1. 永远增长的静态集合

静态字段在 JVM 的生命周期内一直存在。用作缓存且没有驱逐策略的静态 Map 是典型的泄漏。例如：

public class UserCache {
    private static final Map<Long, User> CACHE = new HashMap<>();

    public static void put(Long id, User user) {
        CACHE.put(id, user); // 从不移除
    }
}

每个添加的用户都会永远保留。修复：使用有界缓存，如 Caffeine 或 Guava，并设置大小限制和过期时间。

2. 未关闭的资源

流、连接和读取器必须关闭。如果忘记，本机资源及其 Java 包装器会泄漏。始终使用 try-with-resources：

try (InputStream in = new FileInputStream(file)) {
    // 使用 in
} // 自动关闭

这也适用于数据库连接、HTTP 客户端和线程池。

3. 未移除的监听器和回调

当你注册监听器（例如 addListener）但从未移除它时，发布者会持有监听器的引用，而监听器可能持有你整个对象图的引用。这在 GUI、事件总线和长生命周期上下文中很常见。

4. ThreadLocal 变量

ThreadLocal 值存储在 ThreadLocalMap 中。在线程池中，线程被重用，因此如果不调用 remove()，值会一直附着在线程上并泄漏。始终清理：

try {
    threadLocal.set(context);
    // 工作
} finally {
    threadLocal.remove();
}

5. 内部类持有外部引用

非静态内部类（包括匿名类）持有对外部实例的隐式引用。如果内部类实例比外部对象存活更久（例如存储在静态列表中），外部对象就无法被回收。当内部类不需要外部实例时，将其设为静态。

6. 不正确的 equals() 和 hashCode()

如果在 HashMap 中使用对象作为键，但重写了 equals() 而没有重写 hashCode()（或反之），查找会失败，条目会累积。始终一致地重写两者。

7. 字符串驻留和子字符串

在 Java 7 之前，String.substring() 共享原始字符数组，因此一个小的子字符串可能持有大数组。现代 Java 会复制，但驻留许多唯一字符串（例如 String.intern()）仍可能填满字符串池。

如何检测 Java 内存泄漏

检测遵循系统化的过程。以下是逐步方法：

1. 随时间监控堆使用情况。 使用 JVisualVM、JConsole 或你的 APM。健康的应用程序显示锯齿模式：堆增长，GC 回收，堆下降。泄漏则在每次 GC 后显示基线上升。
2. 启用 GC 日志。 添加 -Xlog:gc*:file=gc.log:time,uptime,level,tags（Java 9+）或 -XX:+PrintGCDetails（Java 8）。使用 GCeasy 等工具分析日志，查看老年代是否持续增长。
3. 捕获堆转储。 当堆高时，运行 jmap -dump:live,format=b,file=heap.hprof <pid> 或使用 jcmd <pid> GC.heap_dump heap.hprof。你还可以通过 -XX:+HeapDumpOnOutOfMemoryError 在 OutOfMemoryError 时触发转储。
4. 分析堆转储。 在 Eclipse MAT 或 VisualVM 中打开它。查看 支配树 以找到保留最多内存的对象。检查具有大保留大小的可疑集合。
5. 进行第二次转储并比较。 如果相同对象在转储之间增长，你就找到了泄漏。
6. 使用分析器进行实时分析。 YourKit、JProfiler 或 async-profiler 等工具可以跟踪分配位置和引用链，而无需停止应用。

以下是常见工具的快速比较：

修复和预防泄漏

一旦你识别出泄漏，通过移除无意的引用来修复它。常见修复方法：

• 将有界缓存替换为有界缓存（Caffeine、Ehcache）。
• 对所有 Closeable 资源使用 try-with-resources。
• 在 finally 块中注销监听器或使用弱引用。
• 始终调用 ThreadLocal.remove()。
• 尽可能将内部类设为静态。
• 同时重写 equals() 和 hashCode()。

预防胜于治疗。将内存监控添加到 CI/CD 管道，运行带有堆检查的负载测试，并适当设置 -Xmx。使用 SpotBugs 等静态分析工具来捕获常见模式。

常见问题

内存泄漏和内存峰值有什么区别？

内存峰值是堆使用量的暂时增加，GC 会回收。泄漏是随时间稳定增加，因为对象保持可达且无法被收集。

即使堆很大，Java 内存泄漏会导致 OutOfMemoryError 吗？

是的。如果泄漏速率超过 GC 的回收能力，堆最终会填满，无论大小。增加堆只会延迟失败。

如何在不停止服务的情况下在生产环境中找到内存泄漏？

使用低开销工具，如 async-profiler 或 JFR（Java Flight Recorder）来记录分配和堆统计信息。你也可以在应用运行时使用 jcmd 触发堆转储，尽管可能会短暂暂停。

需要分析 GC 日志或其他基于文本的日志？试试我们的 Nginx 日志分析器 来快速解析和可视化日志模式。