PhantomReference 必须配合非空 ReferenceQueue 使用，其 get() 永远返回 null，唯一作用是在对象被 GC 回收后入队以触发清理；适用于堆外内存等需确定性清理的场景，但不能替代显式资源释放。
PhantomReference 必须配合 ReferenceQueue 使用，否则毫无意义
虚引用本身不阻止对象被回收，get() 永远返回 null，所以单拿一个 PhantomReference 对象根本拿不到被引用对象的实例。它的唯一合法用法，就是构造时传入一个非空的 ReferenceQueue，等 GC 把对象回收后，JVM 会把该虚引用“入队”到这个队列里——这才是你能感知回收发生的唯一时机。
常见错误是只 new 出来就扔着不管：new PhantomReference(obj, null)，这等于没写；或者误以为能靠 ref.get() 取出对象做清理，实际永远是 null。
- 必须传入非
null的ReferenceQueue实例 - 回收触发点不是 GC 发生时，而是 GC 完成且对象真正不可达后，JVM 主动将虚引用 enqueue 到队列
- 要轮询或阻塞监听
queue.remove()或queue.poll()才能捕获回收信号
为什么堆外内存（如 DirectByteBuffer）用 PhantomReference 做清理哨兵
因为堆外内存不受 GC 直接管理，DirectByteBuffer 在堆内只占很小对象，但背后可能持有几 MB 的 native 内存。JVM 无法自动释放它，必须在堆内对象被回收时，主动调用 Cleaner.clean() 或 Unsafe.freeMemory()。
这里不能用软引用或弱引用：软引用可能长期存活导致堆外内存泄漏；弱引用太“脆”，GC 一来就清，可能还没等你处理完就丢了信号。虚引用刚好卡在“对象已死、但还没被彻底清除”的窗口期，给你一个确定性的、仅一次的清理机会。
-
Cleaner底层就是基于PhantomReference + ReferenceQueue实现的 - 如果你自己封装堆外资源（比如自定义 native buffer），也应照此模式注册虚引用+队列监听
- 注意：
ReferenceQueue里的元素不会自动移除，必须手动remove()或poll()，否则队列堆积会导致内存泄漏
ReferenceQueue.poll() 和 remove() 的行为差异直接影响线程安全
这两个方法看着像只是“是否阻塞”的区别，但实际影响清理逻辑的健壮性。
-
queue.poll()立即返回，取不到就返回null；适合非关键路径或已有轮询机制的场景 -
queue.remove()会一直阻塞，直到有引用入队；适合单独起一个守护线程做清理，避免空转耗 CPU - 如果多个线程同时调用
remove()，只有一个能拿到引用，其余继续阻塞——这不是 bug，是设计使然，确保清理动作不被重复执行 - 别在主线程或响应敏感路径里无超时地调用
remove()，否则 GC 触发延迟可能导致整个线程卡住
容易被忽略的 finalize() 替代陷阱：PhantomReference 不是万能兜底
有人以为用虚引用就能完全替代 finalize() 做资源清理，其实不然。虚引用的入队时机依赖于 GC 的可达性判断和后续的 reference processing 阶段，而这两步都可能被延迟——尤其在低负载、内存充足时，GC 少，队列长时间为空，堆外内存就一直挂着。
更危险的是：如果清理逻辑抛异常，ReferenceHandler 线程会静默吞掉，你完全收不到通知。
- 虚引用适合“尽力而为”的异步清理，绝不能当作同步释放资源的唯一手段
- 关键资源（如文件句柄、socket）仍需显式
close()，虚引用只作为保险 - 监听队列的线程必须自行捕获异常并记录日志，否则失败无声无息
- JDK 9+ 中
Cleaner已取代大部分PhantomReference手动用法，优先考虑用它
虚引用真正的价值不在“一定能清”，而在“清的时候你知道它一定已经不可达了”。这个确定性，是其他引用类型给不了的。
