强引用不回收，哪怕oom也不会动它；软引用在内存不足时才回收，优先级低于弱引用；弱引用每次gc都回收；虚引用仅用于对象销毁通知，无法访问对象。
强引用不回收，哪怕OOM也不会动它
只要一个对象还被strongReference（比如普通变量赋值）直接持有，GC 就绝不会回收它。哪怕堆快炸了、OutOfMemoryError 眼看就要抛，JVM 宁可死也不碰这类对象。
常见错误现象：new byte[1024 * 1024 * 100]反复创建却没显式置null，导致内存持续上涨——不是 GC 不想收，是它根本「看不见」回收入口。
- 使用场景：日常对象生命周期管理，默认行为，无需干预
- 性能影响：零额外开销，但滥用大对象+长生命周期会直接拖垮堆可用空间
- 容易踩的坑：缓存场景下用
HashMap<string bigobject></string>长期持有时，忘了用WeakReference或SoftReference包装值
软引用在GC前被回收，但优先级低于弱引用
SoftReference 的回收时机取决于 JVM 对「内存是否够用」的判断，不是每次 GC 都扫它，而是在即将 OOM 前才批量清理。但它比WeakReference更「抗压」——同样条件下，软引用存活概率更高。
常见错误现象：用SoftReference做图片缓存，发现低内存时图片还是频繁重建——因为 JVM 认为当前堆还有余量，没触发软引用清理阈值。
立即学习“Java免费学习笔记（深入）”；
- 参数差异：
SoftReference内部依赖gcBeforeOom策略，不同 JDK 版本对「临界点」判定略有差异（如 JDK 8 默认基于最近一次 GC 后的空闲空间估算） - 使用场景：内存敏感型缓存，比如解析后的 XML Schema、预加载的图标资源
- 容易踩的坑：误以为「软」=「随时可丢」，结果在低负载下缓存命中率异常高，上线后高并发压测反而因回收延迟导致 OOM
弱引用只要GC一跑就清，不管内存剩多少
WeakReference 是最激进的引用类型，只要发生任意一次 GC（包括 Young GC），它指向的对象若没其他强/软引用，立刻进回收队列。没有「犹豫期」，也不看堆剩余空间。
常见错误现象：用WeakHashMap当缓存，发现 put 进去的数据下一秒就 get 不到——其实是 key 被回收了，而你忘了WeakHashMap的 key 是弱引用，value 依赖 key 存活。
- 使用场景：监听器自动反注册、临时上下文绑定（如 ThreadLocal 的部分实现）、避免内存泄漏的代理容器
- 兼容性影响：所有 JDK 版本行为一致，无版本差异风险
- 容易踩的坑：把
WeakReference当「轻量级缓存」用，却没配合ReferenceQueue做失效通知，导致业务逻辑拿到 null 后 NPE
虚引用只用来收尸，不能阻止回收
PhantomReference 是唯一无法通过引用访问对象实例的类型。它不参与「是否回收」的决策，只在对象被 finalize 之后、真正从内存移除前，发个通知。你拿不到对象，也改不了它的命运。
常见错误现象：试图用get()方法取值，结果永远是null——这是设计使然，不是写错了。
- 使用场景：精确追踪对象销毁时间（如 native 资源释放、堆外内存清理）、替代已废弃的
finalize() - 实操要点：必须配合
ReferenceQueue轮询，且需手动调用clean()类逻辑，JVM 不帮你执行任何清理动作 - 容易踩的坑：漏掉
ReferenceQueue消费逻辑，或在enqueue后没及时remove()，导致队列堆积、元空间缓慢泄漏
GC 对引用的处理不是按「强度等级」线性排队，而是分阶段、看策略、受参数调控。比如-XX:SoftRefLRUPolicyMSPerMB能改软引用存活时间，而WeakReference看似简单，实际在 CMS 或 ZGC 下的回收节奏也不同。别只盯着引用类型本身，得看它跑在哪种 GC 算法里。
