防范内存泄漏的关键是让引用生命周期与业务逻辑对齐：强引用是主因需及时切断；软引用为缓存兜底防oom；弱引用解耦生命周期防隐式持有；虚引用配合队列精准触发资源清理。
防范内存泄漏，关键不是“不用引用”，而是让引用的生命周期与业务逻辑真正对齐。四种引用类型在其中扮演的角色截然不同：强引用是风险主因，软/弱引用是主动减压手段，虚引用则是回收确认机制。
强引用：内存泄漏的主要源头，需主动管理
强引用只要存在，GC 就绝不会回收对象——哪怕它早已无用。这是内存泄漏最常见根源。
- 集合类长期持有对象（如静态 List 不断 add）会持续占用堆内存
- 监听器、回调未反注册，导致被监听对象无法释放
- ThreadLocal 的 value 若为强引用且未 remove，可能引发线程复用场景下的泄漏
- 解决思路不是避免强引用，而是及时切断：显式置 null、清空集合元素、调用 remove() 或 close()
软引用：为缓存兜底，防止 OOM 引发的连锁泄漏
软引用不阻止 GC，但只在内存真正紧张时才被回收。它把“缓存该不该留”交给 JVM 判断，避免开发者硬编码淘汰策略出错。
- 适合图片、模板、计算结果等体积大、可重建的缓存项
- 即使缓存未手动清理，JVM 也会在 OOM 前优先回收软引用对象，相当于加了一层安全阀
- 注意：不能依赖 get() 永远返回非 null；每次使用前必须判空
弱引用：解耦生命周期，消除隐式强引用链
弱引用对象在任意一次 GC（包括 Young GC）中都会被立即回收。它常用于“临时绑定”或“附属关系”，避免因引用滞留延长对象生命。
- WeakHashMap 的 key 是弱引用，当 key 对象被回收，对应 entry 自动失效，避免 Map 成为泄漏容器
- ThreadLocalMap 内部使用弱引用作为 key，防止 ThreadLocal 实例被回收后，value 仍被 map 持有
- 监听器注册时用弱引用包装 listener，可降低因忘记反注册导致的泄漏风险
虚引用：精准感知回收，辅助资源清理闭环
虚引用本身不阻止回收，也无法通过 get() 获取对象。它的价值在于配合 ReferenceQueue，可靠地触发清理动作。
- 典型用于 DirectByteBuffer 的清理：堆外内存不受 GC 管控，需在对象被回收时主动释放 native 资源
- 可替代 finalize()（已弃用），实现更可控、更及时的资源释放钩子
- 避免在 finalize 中执行耗时或依赖其他对象的操作，虚引用 + 队列轮询更安全稳定
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
