PhantomReference 必须配合非 null 的 ReferenceQueue 使用，其 get() 永远返回 null，仅用于在对象被彻底回收后接收通知；remove() 阻塞，需在守护线程中调用；它不延缓回收，只作清理钩子，且 ReferenceQueue 非线程安全、不保证 FIFO。
PhantomReference 不能 get()，但必须配 ReferenceQueue
虚引用的 get() 永远返回 null，它不参与对象可达性判断，也不影响 GC 命运——哪怕只有一条虚引用指向对象，该对象在下一次 GC 时仍可能被回收。它的唯一合法用途，是配合 ReferenceQueue 接收“对象已被 JVM 彻底回收”的通知。没有 queue 的 PhantomReference 是废的：JVM 不会把它入队，你也就永远收不到回收信号。
构造时必须传入非 null 的 ReferenceQueue，否则等同于裸写了个没用的包装器：
PhantomReference<byte> ref = new PhantomReference(new byte[1024 * 1024], queue); // ✅ 正确 PhantomReference<byte> bad = new PhantomReference(new byte[1], null); // ❌ 入不了队，监听失效</byte></byte>
ReferenceQueue.remove() 是阻塞式轮询，别在主线程里直接调用
从 ReferenceQueue 取出已回收的 PhantomReference，最常用的是 remove() 或 poll()。但注意：remove() 会无限期阻塞，直到有引用入队；而 poll() 立即返回 null（无元素时）。线上服务如果在请求线程里调用 remove()，等于主动卡死当前线程。
- 正确做法是起一个守护线程，用
remove()长轮询 - 或者用
poll()+ 短间隔 sleep，适合低频场景 - 千万别在 Spring Controller、Servlet 或 Netty ChannelHandler 里同步调用
remove()
虚引用不是用来“延缓回收”，而是做清理钩子
很多人误以为虚引用能控制对象生命周期，其实完全相反：它只在对象**已经结束 finalize（如果存在）且所有内存页被释放后**，才被 JVM 推入队列。此时对象实例已不存在，referent 字段也早已被 JVM 清空（这也是 get() 总是 null 的原因）。
典型用途只有两类：
- 替代
finalize()做堆外资源清理，比如DirectByteBuffer内部用Cleaner（本质是PhantomReference子类）触发unsafe.freeMemory() - 监控关键对象销毁时机，例如在自定义连接池中，当某个连接对象被回收时，主动关闭底层 socket 或释放 license 计数
如果你试图用虚引用“保护”对象不被回收，或指望它还能访问原对象数据，那逻辑就彻底反了。
ReferenceQueue 的内部是单向链表，不是线程安全的 FIFO 队列
ReferenceQueue 表面像队列，但它的实现非常轻量：靠 JVM 直接操作 pending 和 discovered 链表，Java 层的 remove() / poll() 只是遍历这个链表。它不提供容量限制、超时等待（除了 remove(long)）、或并发控制语义。
这意味着：
- 多个线程同时
remove()不会抛异常，但可能拿到同一个PhantomReference实例（竞态），所以实际使用中几乎总是单消费者线程 - 它不保证先进先出顺序，尤其在高并发入队场景下，顺序取决于 JVM 处理 pending 链表的时机
- 不要把它当成通用任务队列来用，比如往里塞自定义任务对象——它只认
Reference及其子类
真正容易被忽略的一点：一旦 PhantomReference 被 remove() 出来，它就从队列中永久移除，且无法重入。如果清理逻辑抛异常没捕获，这个引用就丢了，后续再也无法响应这次回收事件。
