ReferenceQueue：监控变量对象被回收的机制

苏承栈

2026-10-12 • 👁 0人浏览过

ReferenceQueue 是监控对象实例被回收的通知通道，入队的是WeakReference或PhantomReference等引用对象本身，而非原始对象；需构造时显式传入，通过poll()/remove()轮询确认回收完成。 ReferenceQueue 不是监控“变量”被回收的机制，而是监控对象实例被垃圾回收后发出的通知通道。它不感知变量（如局部变量、字段）是否置为

null

，只在 JVM 完成对象回收、且该对象曾被某 Reference（弱引用、虚引用等）所引用时，把那个 Reference 对象本身放入队列。 ReferenceQueue 的本质：收“通知”，不存对象它内部不保存原始对象（referent），也不记录是谁引用了它。入队的是 PhantomReference 或 WeakReference 这类引用对象的实例——相当于一具“尸体通知单”，而不是尸体本身。你不能对它调用

add()

、

offer()

或任何写入方法；所有入队均由 JVM 自动触发必须在构造引用时显式传入非

null

的队列：

new WeakReference(obj, queue)

若构造时传了

null

队列，回收后就彻底静默，无法感知怎么知道对象真被回收了？靠轮询队列，不是靠 get() == null

WeakReference.get()

null

只表示“可能已被回收”，但存在竞态：GC 尚未执行、或已执行但引用还未入队。真正确认回收完成，唯一可靠方式是队列中取到对应引用：

queue.poll()

：非阻塞，立即返回，适合配合循环与休眠做轻量监听

queue.remove()

：阻塞直到有引用入队，适合守护线程长期运行取到的是

WeakReference

或

PhantomReference

实例，不是原对象；

ref.get()

对虚引用永远为

null

，对弱引用可能为

null

或已失效对象 WeakReference + ReferenceQueue：最常用的存活监听组合适用于想“旁观对象生命周期”又不干扰 GC 的场景，比如缓存淘汰、资源依赖追踪：对象仍有强引用时，弱引用不会入队强引用断开 + GC 执行后，弱引用才可能入队（不保证立刻，也不保证必在下一次 GC）测试时避免依赖

System.gc()

；生产环境绝不主动调用收到通知后，建议立即调用

ref.clear()

，防止弱引用意外被重复使用 PhantomReference + ReferenceQueue：唯一安全的清理入口如果你需要在对象回收后执行确定性清理（如释放堆外内存、关闭 native 句柄），必须用虚引用：

PhantomReference.get()

永远返回

null

，杜绝“复活”或误访问已销毁对象 JVM 只在对象 finalize 完成（若启用）、且彻底不可达后，才将其虚引用入队需单独起线程，用

while

循环持续调用

remove()

或

poll()

每次取到引用后必须手动

remove()

或

poll()

，否则队列堆积会引发内存泄漏

相关文章