强引用禁止GC回收，软引用在OOM前回收，弱引用在每次GC时回收，虚引用仅用于回收通知。四者适用场景不同：强引用防误回收但易致内存泄漏；软引用适合内存敏感缓存；弱引用解决监听器泄漏；虚引用配合ReferenceQueue实现精准资源清理。
强引用就是“死拽着不放”，GC 绝对不敢动它
你写 Object obj = new Object()，这个 obj 就是强引用。只要栈里还存着这行变量（没置为 null、没出作用域），哪怕 JVM 内存快爆了，宁可抛 OutOfMemoryError 也不会回收它。这是内存泄漏最常见源头——比如监听器注册后忘了反注册，被持有强引用，对象就永远卡在堆里。
实操建议：
- 日常开发中 95% 的引用都是强引用，不用特别处理，但要时刻警惕“不该持有时却一直持有”
- 集合类（如
ArrayList、HashMap）默认存的都是强引用，往里塞大对象前要想清楚生命周期 - 全局缓存用强引用没问题，但必须配手动清理逻辑（比如 LRU 驱逐、定时过期），否则等于埋雷
软引用适合做“内存警觉型缓存”，OOM 前才放手
SoftReference 的核心行为：JVM 在真正要 OOM 之前，会扫描并回收所有软引用对象。它不是按时间或访问频次淘汰，而是看堆内存压力——所以叫“内存敏感缓存”。图片、HTML 模板、计算结果这类“丢了能重算，但有则更快”的数据最合适。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
- 以为软引用“一定比弱引用活得久”——其实不一定，取决于 GC 类型和内存压力时机；CMS 和 G1 对软引用的回收策略就有差异
- 没配合
ReferenceQueue监控回收事件，导致缓存失效后无法及时更新状态或触发重加载 - 直接把大数组（如
new byte[100 * 1024 * 1024]）包进SoftReference，但 JVM 可能因元空间/直接内存不足先崩，根本轮不到软引用回收
示例关键点：cache.get(key).get() 返回 null 不代表缓存没命中，只说明对象已被 GC；必须重新加载并再 put 一次。
弱引用专治“随用随丢”，GC 一来就清零
WeakReference 的行为很干脆：只要发生 GC（哪怕只是 Young GC），且对象只被弱引用持有，立刻回收。它不看内存够不够，只看“有没有其他活引用”。典型场景是避免监听器泄漏、实现线程局部映射（ThreadLocalMap 内部 Entry 就是 WeakReference）。
使用场景：
- 注册式回调（如 Android 的
View.setOnClickListener），用弱引用包装 listener，Activity 销毁后 listener 自动失效 -
WeakHashMap的 key 是弱引用，value 跟着 key 一起消失，适合做“临时绑定关系”缓存 - 不能用于需要稳定存在的缓存——因为可能刚 put 进去，下一次 GC 就没了
注意：WeakReference.get() 返回 null 后，该引用对象本身不会自动从容器中移除，得靠 ReferenceQueue 或主动轮询清理，否则容器里堆满 null 引用。
虚引用唯一用途：对象被回收前“打个招呼”
PhantomReference 是个异类：它不能通过 get() 拿到对象（永远返回 null），也不能影响对象生命周期。它的存在只有一个目的——当对象进入 finalize 阶段、即将被回收时，JVM 会把它对应的虚引用加入关联的 ReferenceQueue。你起个守护线程 poll 这个 queue，就能精准知道“某对象刚被回收”。
实操要点：
- 必须传入
ReferenceQueue构造，否则毫无意义（new PhantomReference(obj, null)是非法的） - 常用于资源清理，比如
DirectByteBuffer就用虚引用 + Cleaner（替代已废弃的 finalize）来释放堆外内存 - 别想用它做“延迟回收”或“回收前拦截修改”——对象此时已不可达，任何字段读取都可能 NPE 或返回旧值
容易被忽略的一点：虚引用队列里的元素不是自动清除的，poll 后需手动处理，否则 queue 会无限堆积虚引用对象本身（它们很小，但也是对象）。
