ReferenceQueue 通过接收被回收的 WeakReference 实例实现缓存清理：需显式关联队列，轮询或监听出队事件，及时从 Map 中移除 key 并 clear 引用，否则导致内存泄漏。
ReferenceQueue 是怎么配合 WeakReference 清理缓存的
WeakReference 本身不自动触发清理，它只告诉 GC “这个对象可以被回收”，但回收后不会主动通知你。真正让“自动清理”落地的是 ReferenceQueue：当 JVM 回收一个被 WeakReference 引用的对象时，会把该 WeakReference 实例入队到关联的 ReferenceQueue 中——你得自己轮询或监听这个队列，才能感知到清理时机。
这意味着：不能只 new 一个 WeakReference 就完事；必须显式构造 ReferenceQueue，并把它传给引用构造器，否则队列永远为空。
-
new WeakReference(sensitiveData, referenceQueue)—— 必须传参，否则队列失效 - 队列中取出的是
WeakReference对象本身，不是原始数据，需调用get()检查是否已为null - 队列是线程安全的，但出队操作（
poll()或remove()）需你自己安排执行时机，常见做法是另起守护线程或在缓存读写路径中轻量检查
敏感数据缓存结构里为什么不能直接存 WeakReference
因为 WeakReference 只能持有单个对象引用，而缓存需要支持 key 查找、过期控制、并发访问等能力。直接拿 WeakReference 当缓存项，会导致无法通过 key 定位、无法批量清理、无法区分不同敏感数据实例等问题。
正确做法是用 Map 做外壳，再辅以独立的 ReferenceQueue 监听所有弱引用的回收事件。
- key 必须是强引用（如
String或自定义不可变 key 类），否则整个缓存条目可能被提前回收 - value 存
WeakReference，但建议包装一层（如SoftReference或自定义SensitiveRef），方便附加元信息（创建时间、用途标识） - 避免使用
ConcurrentHashMap的弱值映射——JDK 不提供原生支持，强行用会导致 key 强引用但 value 回收后 map 中残留 null-value 条目，污染 size 统计和遍历逻辑
ReferenceQueue.poll() 和 remove() 的实际选择策略
两者都从队列取已入队的引用，但行为差异直接影响缓存清理的实时性与线程阻塞风险：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
poll()立即返回，队列空则返回null；适合在缓存 get/put 方法中非阻塞检查，开销小，但可能漏掉刚回收还没来得及处理的引用 -
remove()会阻塞直到有引用入队（可带超时）；适合单独起后台线程长期监听，保证不漏，但若缓存压力小、回收少，线程会长时间挂起 - 生产环境更推荐混合用法：主业务路径用
poll()快速清理；另启一个低优先级守护线程，用remove(100)（100ms 超时）循环处理，兼顾响应与完整性
为什么清理动作里要先 remove(key)，再 clear() 弱引用
这是最容易出错的一环：很多实现只调用 reference.clear()，却忘了从缓存 map 中移除 key → 导致 key 永远滞留，map.size() 持续增长，最终 OOM。
clear() 只是切断 WeakReference 对目标对象的链接，对 map 结构毫无影响；而 map 的 key 仍存在，下次 get 时会拿到一个 get() == null 的引用，还得二次判断，徒增开销。
- 必须在处理队列中引用时，同步执行
cacheMap.remove(key)（注意：key 需从引用对象中提前保存，因为引用回收后无法反查） - 推荐在构造
WeakReference子类时，把 key 作为字段传入，例如：new SensitiveRef(data, queue, cacheKey) - 如果 key 是计算得出（如 MD5），务必确保计算过程无副作用、线程安全，且不依赖已被回收的数据状态
敏感数据缓存的难点不在引用类型选择，而在清理路径的原子性和 key 生命周期管理——稍不注意，就变成“弱引用没起作用，强引用 key 却堆满内存”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
