Java四种引用按需分级使用：强引用默认不回收，适用于核心对象但易致内存泄漏；软引用内存紧张时回收，适合缓存；弱引用GC即回收，用于避免隐形泄漏；虚引用仅监控回收，配合队列做资源清理。
Java 垃圾回收中，四种引用不是“选哪个更好”，而是“按需分级使用”——它们本质是 JVM 提供给开发者的内存控制开关，关键在于理解每种引用的回收行为边界，并匹配真实场景。
强引用：默认且最“霸道”，用完记得松手
强引用就是日常写的 Object obj = new Object()。只要 obj 还在作用域内、没被置为 null、也没被覆盖，JVM 就绝不会回收它，哪怕 OOM 也宁可崩溃不妥协。
- 适合长期存活的核心对象，比如单例实例、配置类、数据库连接池中的活跃连接
- 风险点在于容易引发内存泄漏：例如集合里存了强引用监听器却忘了 remove；或 ThreadLocal 中存了大对象又没调用 remove()
- 主动管理技巧：方法内临时对象无需干预；全局缓存/监听列表用完后及时 obj = null 或清空容器元素（如 ArrayList.clear() 中逐个设为 null）
软引用：做“有底线的缓存”，靠它防 OOM
软引用对象在 JVM 内存真正吃紧、即将抛 OutOfMemoryError 前才会被回收。它不是“等 GC 来就收”，而是“等内存告急才收”，因此天然适合作为缓存兜底机制。
- 典型场景：图片缩略图缓存、查询结果缓存、JSON 解析中间对象
- 使用时必须配合 get() 判空：因为随时可能返回 null，不能假设一定存在
- 建议搭配引用队列（ReferenceQueue）：当软引用被回收，可触发日志、统计或预加载逻辑，实现缓存失效感知
弱引用：解决“绑定生命周期”的问题，避免隐形泄漏
弱引用对象在下一次 GC 触发时必然被回收，不管内存多富裕。它的价值不在“保活”，而在“不阻碍回收”——让对象生命周期严格跟随其强引用持有者。
立即学习“Java免费学习笔记（深入）”；
- 最经典应用：WeakHashMap 的 key，确保 key 对象被回收后，对应 entry 自动消失，避免 map 持久引用导致 key 无法释放
- ThreadLocal 的内部实现也用弱引用作 key，防止线程长期运行时，本该回收的 value 因 key 被强持而泄露
- 监听器注册场景：用 WeakReference 包装 listener，避免 Activity 销毁后 listener 仍被 manager 持有
虚引用：不为保对象，只为“盯回收”，配合资源清理
虚引用最特殊：它永远 get() 不出对象（始终返回 null），也无法影响对象存活。唯一作用是——当对象被 GC 回收前，JVM 会把该虚引用加入关联的 ReferenceQueue，通知你“它要没了”。
- 必须与 ReferenceQueue 配合使用，否则毫无意义
- 典型用途：堆外内存（如 DirectByteBuffer）清理、文件句柄关闭、自定义 finalize 替代方案
- 注意：它不是替代 finalize()，而是更可控、无延迟的回收钩子；但不能在队列中执行耗时操作，应快速移交到业务线程处理
