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()，否则队列堆积会引发内存泄漏
