ReferenceQueue 轮询比 finalize() 更可靠，因 finalize() 已弃用且调用不保证，而 ReferenceQueue 在 GC 后确定性入队，poll()/remove() 可靠获取通知；WeakReference+ReferenceQueue 无法直接清理资源，因入队的是引用本身，原对象已被回收，关键信息需提前固化到引用子类中；PhantomReference 才适合敏感资源回收，其 get() 永远返回 null 且强制绑定队列，杜绝对象复活，且与 finalize() 互斥；轮询应使用守护线程阻塞 remove()，避免高频 poll() 和 System.gc() 依赖；ReferenceQueue 仅通知，资源释放须显式、线程安全地执行。
ReferenceQueue 轮询为什么比 finalize() 更可靠
因为 finalize() 已被弃用，JVM 不保证调用时机、次数甚至是否调用；而 ReferenceQueue 是 GC 回收后**确定性入队**的信号通道，只要引用对象被回收，它就一定会进队（前提是构造时正确绑定）。轮询 poll() 或阻塞 remove() 都能拿到通知，不依赖任何回调钩子。
常见错误是误以为 finalize() 能兜底资源释放——它可能永远不执行，或在 Full GC 时才触发，导致文件句柄、数据库连接长期泄漏。
WeakReference + ReferenceQueue 不能直接清理资源的原因
ReferenceQueue 里入队的是 WeakReference 实例本身，不是它曾指向的原始对象。原始对象在入队前已被 GC 回收，get() 返回 null，业务上下文（如文件路径、连接 ID）已不可访问。
所以必须提前把关键信息“固化”到引用对象中：
- 继承
WeakReference，把 resource ID、超时时间等存为字段 - 避免用
Map<WeakReference, Resource>：ref 入队后，Resource仍留在 map 中，造成泄漏 - 推荐用
ConcurrentHashMap<WeakReference<?>, ResourceMeta>，配合定时扫描清理
PhantomReference 才是敏感资源回收的正确选择
如果资源涉及堆外内存、文件句柄、JNI 资源等**必须严格防止复活**的场景，WeakReference 不够安全：get() 在回收前仍可返回原对象，存在被意外访问的风险。
PhantomReference 的 get() 永远返回 null，且构造时 ReferenceQueue 参数是 mandatory 的，漏传直接编译失败：
PhantomReference<MyResource> ref = new PhantomReference<>(resource, queue);
注意：PhantomReference 和 finalize() 互斥——一旦对象关联了虚引用，finalize() 绝对不会被调用。
轮询策略与线程安全边界
poll() 和 remove() 是线程安全的，但 GC 线程入队和你的业务线程轮询之间存在微小窗口，不能假设“刚 GC 就立刻 poll 到”。生产环境应：
- 在守护线程中用
queue.remove()阻塞等待，避免空转 CPU - 避免在高频业务线程中频繁
poll()，可结合指数退避或固定间隔（如 100ms） - 别依赖
System.gc()触发测试——它只是建议，JVM 可忽略；测试时可用-XX:+PrintGCDetails观察实际回收日志
最易被忽略的一点：ReferenceQueue 本身不做任何资源释放，它只负责“通知你该动手了”。close、free、unmap 这些动作，必须由你显式调用，且需处理并发竞争（比如多个线程同时 poll 到同一 ref）。
