软引用缓存不会自动清理过期对象，因其仅响应内存压力而非时间或业务规则；需手动绑定ReferenceQueue并轮询处理回收通知，且须自行实现key关联、并发安全与空值清理。
软引用缓存为什么不会自动清理过期对象
软引用（SoftReference）本身不带过期逻辑，JVM 只在内存压力大时才回收它，和“缓存过期”是两回事。你往 SoftReference 里塞一个对象，哪怕它逻辑上已失效（比如缓存数据陈旧、HTTP 响应过期），只要没触发 GC，它就一直挂着——这不是 bug，是设计如此。
- 软引用只响应内存压力，不响应时间、版本、业务规则等任何外部信号
-
ReferenceQueue不会主动轮询或触发清理，它只是个“回收通知收件箱”，得你自己去取 - 不手动关联
ReferenceQueue并轮询/处理，就等于没启用过期机制
如何用 ReferenceQueue 捕获软引用失效事件
关键不是“创建软引用”，而是让每个 SoftReference 和同一个 ReferenceQueue 绑定，然后在合适时机调用 queue.poll() 或 queue.remove() 拿到被回收的引用实例，再从中提取原始 key 或元数据做缓存剔除。
- 必须在构造
SoftReference时传入ReferenceQueue，例如：new SoftReference(value, queue) - 不能依赖 GC 立即发生，所以需在业务低峰、或每次 get/put 缓存时顺手调用一次
queue.poll() - 从队列取出的是
SoftReference实例本身，不是原始 value，要靠它持有的get()结果是否为null判断是否已回收 - 别在 finalize 或 shutdown hook 里等队列清空——可能永远等不到
为什么不能只靠 ReferenceQueue 做完整缓存管理
ReferenceQueue 只告诉你“某个软引用被回收了”，但不告诉你“该清理哪条缓存记录”“要不要重建”“是否影响其他 key”。它只是一个被动钩子，不是缓存框架。
- 没有 key 关联：
SoftReference默认不保存 key，你要自己包装一层（比如继承或组合SoftReference，加key字段） - 无并发保护：多个线程同时 poll 队列 + 清理 map，得自己加锁或用
ConcurrentHashMap配合computeIfPresent - 无法区分“回收”和“未使用”：软引用被回收后，map 里还留着 null-value 条目，得额外清理，否则内存泄漏风险仍在
- Android 上软引用更不可靠：低内存时优先回收软引用，但某些 ROM 会提前回收，行为比标准 JVM 更激进
替代方案比硬撸 ReferenceQueue 更实际
真要实现带过期的软引用缓存，直接用 Caffeine 或 Guava Cache 是更稳的选择——它们内部确实用了 ReferenceQueue，但把 key 关联、定时/访问驱逐、并发清理全封装好了。
立即学习“Java免费学习笔记（深入）”；
-
Caffeine.newBuilder().softValues().expireAfterWrite(10, TimeUnit.MINUTES)—— 一行启用软引用 + 过期 - 自己手写容易漏掉弱引用与软引用混用场景（比如 key 用
WeakReference，value 用SoftReference），而成熟库已处理好边界 - 调试时你会发现，
ReferenceQueue的消费时机极难预测，尤其在高吞吐服务中，poll 频率低则延迟高，高则浪费 CPU
真正卡住人的，从来不是怎么把 SoftReference 和 ReferenceQueue 接上，而是怎么保证 key 能被反查、清理不漏、线程安全、且不影响主路径性能——这些细节藏在每一行看似简单的 queue.poll() 后面。
