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<Object> cache = new ArrayList<>()是高频泄漏源：只要类没卸载，这个列表及其所有元素就永远存活 - 内部类持有外部类隐式引用，若该内部类被线程池或监听器长期持有（如
new Thread(new Runnable() { ... })），整个外部实例也跟着泄漏 - 使用
ThreadLocal后未调用remove()：在线程复用场景（如 Tomcat 线程池）下，value 会随线程生命周期滞留，且 key 是弱引用，可能提前被清，留下“脏 entry”
如何定位真实的内存泄漏点而非 GC 假象
频繁 Full GC 不等于内存泄漏，可能是堆太小、分配速率过高，或只是老年代碎片化。关键看 java.lang.OutOfMemoryError: Java heap space 是否伴随 GC overhead limit exceeded 或堆使用率持续攀高不回落。
推荐组合排查路径：
立即学习“Java免费学习笔记（深入）”；
- 启动时加
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof，OOM 后直接分析快照 - 用
jstat -gc <pid>观察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 区，不参与常规回收；若频繁分配大数组或大集合，又没及时清理，极易撑爆老年代
ByteBuffer.allocateDirect()）这些非堆区域的问题。堆外内存泄漏不会体现在 hprof 里，得靠 pmap -x <pid> 或 Native Memory Tracking（-XX:NativeMemoryTracking=detail）来确认。 
