Java内存泄漏与垃圾回收的核心问题_技术教程

Java中易致内存泄漏的引用类型包括强引用（未置null或超作用域）、弱引用误用（如WeakHashMap中key未重写equals/hashCode）、静态集合滥用、内部类隐式引用、ThreadLocal未remove等。

Java中哪些引用类型会导致内存泄漏

强引用（Object obj = new Object()）最常见，只要它没被显式置为 null 或超出作用域，GC 就不会回收对应对象。但真正容易埋雷的是弱引用误用和静态集合滥用。

比如把 WeakHashMap 当成“自动清理缓存”用，却往 key 里塞了非重写 equals()/hashCode() 的自定义对象——WeakHashMap 内部仍用 == 判断 key 是否被回收，结果 key 被回收后，value 却因引用链残留而无法释放。

static List 是高频泄漏源：只要类没卸载，这个列表及其所有元素就永远存活
内部类持有外部类隐式引用，若该内部类被线程池或监听器长期持有（如 new Thread(new Runnable() { ... })），整个外部实例也跟着泄漏
使用 ThreadLocal 后未调用 remove()：在线程复用场景（如 Tomcat 线程池）下，value 会随线程生命周期滞留，且 key 是弱引用，可能提前被清，留下“脏 entry”

如何定位真实的内存泄漏点而非 GC 假象

频繁 Full GC 不等于内存泄漏，可能是堆太小、分配速率过高，或只是老年代碎片化。关键看 java.lang.OutOfMemoryError: Java heap space 是否伴随 GC overhead limit exceeded 或堆使用率持续攀高不回落。

推荐组合排查路径：

启动时加 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof，OOM 后直接分析快照
用 jstat -gc 观察 OU（老年代使用量）是否单向增长，同时 OC（老年代容量）不变；若 OU 长期 >90% 且每次 GC 后仅下降少量，大概率泄漏
避免只看 jmap -histo：它只统计类实例数，看不出谁在持有着些实例；要用 jhat 或 VisualVM 打开 hprof，按“Paths from GC Roots”查强引用链

System.gc() 和 finalize() 对泄漏诊断的实际干扰

显式调用 System.gc() 会打乱 JVM 的 GC 节奏，掩盖真实分配压力；而重写 finalize() 更危险——它会让对象从“可回收”变成“待终结”，进入 Finalizer 队列，延迟至少一个 GC 周期才能真正回收，还可能因 finalize() 执行慢或抛异常导致队列积压，最终引发 java.lang.OutOfMemoryError: GC Overhead Limit Exceeded。

现代 JDK（9+）已弃用 finalize()，应改用 Cleaner 或 PhantomReference + 引用队列手动管理资源清理。

不要在 finalize() 中重新建立强引用（如 this.someField = new Object()），这会让对象“复活”，彻底绕过 GC
System.gc() 在生产环境应禁用；若用于测试，需配合 -XX:+DisableExplicitGC 验证其无效性
Cleaner 不依赖 GC 触发时机，而是由 JVM 在对象不可达后异步调度，更可控

G1 GC 下容易被忽略的泄漏诱因

G1 默认启用 -XX:+UseStringDeduplication，对重复字符串做去重，但该功能依赖 String 的 char[] 引用关系。若代码大量使用 substring()（JDK 7u6 以前）或 new String(byte[], ...) 构造出共享底层数组的字符串，去重逻辑可能意外延长原始大数组的生命周期。

JDK 8u20+ 中 String.substring() 已不再共享数组，但手动用 Arrays.copyOfRange() 复制字符数组再构造 String 仍可能引发类似问题
G1 的混合 GC（Mixed GC）只回收部分 Region，若泄漏对象分散在多个 Region 中，可能连续几次混合 GC 都没覆盖到，造成“泄漏节奏慢于 GC 节奏”的假象
开启 -XX:+PrintGCDetails 后注意 Humongous Allocation 日志：大对象（>50% Region size
）直接进 Humongous 区，不参与常规回收；若频繁分配大数组或大集合，又没及时清理，极易撑爆老年代

实际排查时，最常卡在“看到对象没被回收，就认定是泄漏”，却忽略了 ClassLoader 持有、JNI 全局引用、或 native 内存（如 ByteBuffer.allocateDirect()）这些非堆区域的问题。堆外内存泄漏不会体现在 hprof 里，得靠 pmap -x 或 Native Memory Tracking（-XX:NativeMemoryTracking=detail）来确认。