如何在 Java 中利用 SoftReference 结合 ReferenceQueue 实现对缓存对象回收的实时监控

简单来说，当 SoftReference 与 ReferenceQueue 搭配使用时，一旦 JVM 内存吃紧、GC 回收了软引用所指向的对象，对应的 SoftReference 实例就会自动进入这个队列。后台线程只需轮询队列，就能实时感知哪些缓存已被回收，并及时做出响应。

在实际的缓存设计中，常会遇到这样的需求：希望缓存能在内存紧张时自动释放，同时又能精确获知哪个缓存项被回收，以便清理关联状态或更新统计。将 SoftReference 与 ReferenceQueue 绑定就是一套非常成熟的解决方案。

SoftReference 与 ReferenceQueue 的协作机制

SoftReference 本身是一种“软可达”引用，它的核心特点是：当 JVM 内存不足时，GC 会优先回收其指向的对象。如果在创建 SoftReference 时传入了 ReferenceQueue，那么一旦被引用的对象被回收，SoftReference 实例自身（注意，不是原对象）就会被自动加入队列。这正是实现“回收通知”的关键——通过轮询或阻塞式读取 ReferenceQueue，就能及时知道哪些缓存项已经失效。

构建可监控的软引用缓存容器

具体到实现，建议封装一个基于 Map + SoftReference + ReferenceQueue 的缓存类，几个要点值得留意：

• 使用 ConcurrentHashMap 存储 key → SoftReference 的映射，保证并发安全。
• 初始化时绑定一个专用的 ReferenceQueue，所有创建的 SoftReference 都关联它。
• 提供一个后台线程（或定时任务）持续调用 queue.poll() 或 queue.remove(timeout)，检查是否有待处理的引用。
• 从队列取出的 SoftReference 实例，通过 get() 判断是否已返回 null（表示对象已被回收），再执行自定义逻辑，比如记录日志、触发回调或更新统计。

避免常见陷阱

实际开发中，有几个细节容易被忽略：

• 不要单纯靠 queue.isEmpty() 判断是否有回收发生——入队存在延迟，且可能有竞争；应该用循环 poll/remove 配合空值检测。
• SoftReference 实例本身需要携带 key 信息，否则从队列取出后无法知道是哪个缓存项被回收。可以在构造时扩展 SoftReference 或包装成内部类，把 key 绑定进去。
• ReferenceQueue 不会自动清理已取出的引用，需要手动取出并丢弃，否则会持续占用队列内存。
• JDK 版本差异也要注意：JDK 9+ 中 ReferenceQueue 的 remove(timeout) 表现更可靠；JDK 8 及以前建议使用带超时的 poll，避免无限阻塞。

简易示例片段

下面是一个最小可行的监控结构示意：

private final ReferenceQueue