ReferenceQueue 通过 JVM GC 时将失效 Reference 入队触发，需显式构造并手动 poll/remove 清理；软引用缓存须配合 ConcurrentHashMap 等结构防击穿，且清理逻辑应置于 put() 入口以避免内存泄漏。
ReferenceQueue 是怎么被触发的
它不会自动轮询，也不会主动通知你对象被回收了——只有当 JVM 在 GC 过程中发现某个 Reference（比如 SoftReference）所引用的对象可被回收时，才会把该 Reference 实例本身入队到关联的 ReferenceQueue 中。换句话说，ReferenceQueue 存的是“已被断开连接的引用对象”，不是原对象。
常见错误现象：queue.poll() 一直返回 null，以为没生效，其实是还没发生 GC，或者对象还够“软”（没到内存压力阈值）；又或者忘了在构造 SoftReference 时传入 ReferenceQueue 实例。
- 必须显式构造：比如
new SoftReference<string>(str, queue)</string>，不传 queue 就永远收不到通知 - GC 后需手动调用
queue.poll()或queue.remove()拿出失效引用，否则队列会越积越多 -
remove()会阻塞，poll()立即返回，生产环境优先用poll()避免线程卡住
软引用缓存为什么不能只靠 get() 判断存活
SoftReference.get() 返回 null 只说明“此刻不可达”，但无法区分是刚被 GC 回收，还是压根没放进缓存、或 key 写错了。更麻烦的是：多个线程可能同时看到 null，然后各自重建对象，造成重复加载和资源浪费。
使用场景：做内存敏感型缓存（如图片解码结果、模板渲染上下文），既要尽量留着，又不能 OOM。
立即学习“Java免费学习笔记（深入）”；
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 不能把
get()结果直接当缓存命中处理，得配合外部结构（比如ConcurrentHashMap）记录 key → reference 映射 - 每次取值前先
get()，为null时再加锁重建，并把新SoftReference放回 map —— 否则并发下缓存击穿风险极高 - 软引用对象即使没被回收，也可能因 JVM 内存策略提前清空（如 HotSpot 的 -XX:SoftRefLRUPolicyMSPerMB 参数影响），不能当成强一致性保障
ReferenceQueue 和 WeakHashMap 的行为差异
WeakHashMap 内部确实用了 ReferenceQueue，但它只用于清理 key，且清理时机不可控：只有当下一次调用 size()、get()、put() 等方法时，才顺带扫描并移除已入队的 key 条目。这不是实时的，也不是专用线程做的。
而你自己配 ReferenceQueue + SoftReference，控制权完全在手：可以定时扫、可以 GC 后立即扫、也可以在缓存 put 前主动 poll 一遍清理陈旧项。
-
WeakHashMap不适合 value 大、需要主动释放资源的场景（比如缓存了ByteBuffer或文件句柄） - 它的 key 被回收后，entry 仍留在内部数组里，直到下次哈希操作触发清理 —— 可能长期占用内存
- 如果你要清理的是 value（比如缓存值本身占内存多），必须自己管理
ReferenceQueue，WeakHashMap帮不上忙
清理逻辑放在哪里最容易漏掉
最常被忽略的位置是：缓存容器的 put() 入口。很多人只在 get() 里检查是否失效，却没在写入新值前清理队列里的旧引用，导致 ReferenceQueue 积压、map 中残留大量 null value 的映射、甚至 OutOfMemoryError: GC overhead limit exceeded。
性能影响：频繁 poll() 几乎无开销；但若一次积压几千个，批量清理可能引起 minor GC 波动。
- 建议在每次
put()开始时，循环queue.poll()直到返回null，逐个从缓存 map 中 remove 对应 key - 不要用
queue.remove()配 while 循环，它可能无限阻塞（尤其测试时没触发 GC） - 如果缓存读远大于写，也可以另起一个低频调度任务（比如每 5 秒）清理，但必须确保清理逻辑是幂等的
ReferenceQueue 不是开关，它是个被动管道；软引用也不是缓存开关，它只是给 JVM 递了个“可商量”的请求。真正稳住缓存水位的，是你对入队、出队、映射维护这三步节奏的控制精度。
