强引用导致内存泄漏的典型场景是缓存、监听器未反注册及非静态内部类隐式持有外部实例；解决需控制生命周期，用弱/软引用替代，并注意ReferenceQueue需主动消费。
强引用导致内存泄漏的典型场景
强引用是默认引用类型，只要对象被强引用指向，GC 就绝不会回收它。问题不在于“用不用”，而在于“什么时候该断开”。常见踩坑点是缓存、监听器、内部类持有外部实例。
- 静态集合（如
static Map<String, Object>）长期持强引用，key 不失效 → 对象永远不回收 - 注册了回调但没反注册（如
addWindowFocusChangeListener），Activity 被销毁后仍被 View 持有 - 非静态内部类（如 Handler、Runnable）隐式持有外部 Activity 引用，造成整个 Activity 无法释放
解决思路不是消灭强引用，而是控制生命周期：用弱/软引用替代静态缓存中的 value；用 WeakReference<Context> 包装内部类持有的上下文；注册监听时记下 listener 实例，onDestroy 里显式 remove。
SoftReference 和 WeakReference 的选择依据
两者都用于“可回收但尽量保留”的场景，区别在 GC 触发时机：SoftReference 在内存不足（OOM 前）才回收；WeakReference 只要 GC 运行就可能回收。选错会导致缓存频繁失效或内存持续飙高。
- 做内存敏感型缓存（如图片解码后的 Bitmap）→ 用
SoftReference，它更“懒”，适合靠内存压力自然淘汰 - 做生命周期绑定（如 Activity 中的临时回调、View 的 context 持有）→ 用
WeakReference，避免因 GC 延迟导致内存残留 - 注意：
SoftReference.get()和WeakReference.get()都可能返回null，必须判空，不能假设一定有值
示例：new SoftReference<Bitmap>(bitmap) 存入 LRU 缓存，比直接存 Bitmap 多一层保护，但不解决 key 泄漏问题 —— key 本身也得是弱/软的，或用 WeakHashMap。
立即学习“Java免费学习笔记（深入）”；
PhantomReference 为什么几乎没人用对
虚引用不阻止 GC，唯一合法用途是配合 ReferenceQueue 实现对象被回收后的清理动作（如释放堆外内存）。但它不能访问对象内容（get() 永远返回 null），且必须手动轮询队列，写错就等于没写。
- 常见误用：试图用
PhantomReference替代finalize()做资源清理 → finalize 已废弃，但 PhantomReference 不是它的平替，它没有“对象还活着”的上下文 - 正确姿势：分配 DirectByteBuffer 后，用
PhantomReference<ByteBuffer>关联ReferenceQueue，在队列中收到通知后调用Unsafe.freeMemory() - 性能代价：每次 enqueue 都触发一次 JNI 调用，高频对象慎用；建议只用于少量关键资源（如大块堆外内存、文件句柄）
多数人该用 Cleaner（Java 9+）替代：它底层封装了 PhantomReference + Queue，API 更安全，比如 Cleaner.create().register(obj, cleanupAction)。
ReferenceQueue 的实际使用陷阱
所有 Reference 子类（除了强引用）都可以关联 ReferenceQueue，但很多人忽略队列必须主动消费，否则引用对象堆积在队列里，反而成为内存泄漏源。
- 队列本身不自动清理：
queue.poll()或queue.remove()必须被调用，否则PhantomReference等对象一直留在队列中，且其 referent 已为 null，无意义地占内存 - 多线程下需注意：队列操作不是线程安全的，如果多个线程同时注册 Reference，消费端要用循环 +
queue.remove(0)避免阻塞 - 容易混淆：ReferenceQueue 存的是 Reference 对象（如
SoftReference实例），不是它引用的原始对象 —— 别试图从队列里取业务数据
最简健壮模式：起一个低优先级守护线程，死循环 queue.remove()，收到后执行对应清理逻辑。别依赖主线程或某个 Activity 生命周期去清队列。
Reference 体系不是银弹，它把 GC 决策权部分让渡给开发者，但没降低复杂度 —— 相反，你得同时理解 GC 算法行为、引用可达性状态转移、以及队列消费时机。最容易被忽略的是：Reference 对象本身也是对象，也要被 GC；如果 Reference 没被任何地方引用，它自己先被回收，那就永远收不到通知。
