在 java 中，phantomreference（虚引用）无法通过 .get() 获取对象实例，因此不能像 weakreference 那样直接用于资源释放。它必须配合 referencequeue 使用，由后台线程监控队列中的入队事件来触发清理逻辑。在 try-with-resources 的上下文中，通常的做法是：将需要被虚引用的大对象包装进一个自定义的 autocloseable 实现类中，该类内部持有对目标对象的 phantomreference 和关联的 referencequeue；当 try-with-resources 块结束时，调用链会执行该类的 close() 方法，但真正的“软性”回收通知依赖于 jvm gc 将 phantomreference 推入 referencequeue 后，由专门的监听线程读取并执行后续操作。
如何构建支持 PhantomReference 的资源包装器
要实现这一机制，核心在于创建一个实现了 AutoCloseable 接口的包装类。这个类在构造时接收目标对象和一个 ReferenceQueue，并初始化一个 PhantomReference。关键在于，PhantomReference 必须在目标对象仍然可达时被创建，否则它会立即入队。在 close() 方法中，我们可以选择阻塞等待队列中的引用，或者仅做标记。通常，为了配合 try-with-resources 的非阻塞特性，close() 方法本身不执行重型清理，而是确保引用被正确注册，真正的清理工作由轮询 ReferenceQueue 的守护线程完成。
import java.lang.ref.PhantomReference;
import java.lang.ref.Reference;
import java.lang.ref.ReferenceQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;
public class PhantomResource implements AutoCloseable {
private final Object resource;
private final PhantomReference<object> phantomRef;
private final BlockingQueue<phantomresource> queue;
public PhantomResource(Object resource, ReferenceQueue<object> refQueue, BlockingQueue<phantomresource> cleanupQueue) {
this.resource = resource;
// 关键：PhantomReference 必须在对象可达时创建
this.phantomRef = new PhantomReference(resource, refQueue);
this.queue = cleanupQueue;
}
@Override
public void close() throws Exception {
// try-with-resources 调用 close 时，对象可能仍被其他强引用持有
// 这里我们只是确保引用已注册，实际清理由后台线程处理
System.out.println("Try-with-resources block exited. Scheduling potential cleanup.");
}
public boolean isEnqueued() {
return phantomRef.isEnqueued();
}
}</phantomresource></object></phantomresource></object>
上述代码展示了基本结构。注意 phantomRef 的创建时机。如果 resource 在构造前已被回收，phantomRef 会立即入队。在实际应用中，通常需要结合 SoftReference 或 WeakReference 来管理缓存，而 PhantomReference 专门用于追踪那些不再被任何常规引用链可达、即将被彻底回收的对象。
后台清理线程如何消费 ReferenceQueue
仅仅创建 PhantomReference 是不够的，必须有一个活跃的线程不断检查 ReferenceQueue。当 JVM 发现某个对象只剩下虚引用时，在下次 GC 期间，该对象会被回收，同时对应的 PhantomReference 会被放入关联的 ReferenceQueue 中。我们需要一个独立的守护线程来轮询这个队列。一旦检测到新的引用入队，就可以执行特定的清理动作，比如关闭非堆内存资源（如 DirectByteBuffer）、记录日志或通知外部系统。
import java.lang.ref.PhantomReference;
import java.lang.ref.Reference;
import java.lang.ref.ReferenceQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;
public class CleanupMonitor extends Thread {
private final ReferenceQueue<object> queue;
private final BlockingQueue<phantomresource> pendingCleanup;
private volatile boolean running = true;
public CleanupMonitor(ReferenceQueue<object> queue, BlockingQueue<phantomresource> pendingCleanup) {
super("Phantom-Cleanup-Thread");
this.queue = queue;
this.pendingCleanup = pendingCleanup;
setDaemon(true); // 设置为守护线程，JVM 退出时自动终止
}
@Override
public void run() {
while (running) {
try {
// 阻塞等待，直到有 PhantomReference 入队
Reference> ref = queue.remove();
if (ref instanceof PhantomReference) {
// 这里可以强制转换为具体的类型以获取更多信息
// 由于 PhantomReference.get() 总是返回 null，
// 我们通常需要在创建时就将相关元数据绑定到包装对象上
System.out.println("PhantomReference enqueued: " + ref);
// 模拟将待清理任务加入队列
// 实际场景中，可能需要从 ref 中提取上下文
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
break;
}
}
}
public void stopMonitoring() {
running = false;
}
}</phantomresource></object></phantomresource></object>
在这个模式中，queue.remove() 是一个阻塞调用，它会一直等待直到有引用入队。这确保了清理操作的及时性。需要注意的是，PhantomReference 的 get() 方法始终返回 null，这是其设计意图：它不提供访问对象的方法，只提供一个在对象死亡后收到通知的机制。因此，所有需要在清理阶段使用的信息，都必须在创建 PhantomReference 时就封装在包装对象或其他数据结构中。
try-with-resources 与 PhantomReference 的生命周期冲突如何解决
一个常见的问题是：try-with-resources 保证在块结束时调用 close()，但这并不意味着对象可以被 GC 回收。如果 close() 方法内部还持有对该对象的强引用，或者对象被其他变量引用，那么 PhantomReference 就不会入队。为了解决这个问题，必须确保在 try-with-resources 块结束后，除了 PhantomReference 之外，没有任何其他强引用指向该资源。这意味着 close() 方法应该尽快释放所有强引用，或者将资源的作用域限制在 try 块内。
import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;
public class Main {
public static void main(String[] args) throws Exception {
ReferenceQueue<object> refQueue = new ReferenceQueue();
BlockingQueue<phantomresource> cleanupQueue = new LinkedBlockingQueue();
// 启动清理监控线程
CleanupMonitor monitor = new CleanupMonitor(refQueue, cleanupQueue);
monitor.start();
// 使用 try-with-resources
try (PhantomResource res = new PhantomResource(new Object(), refQueue, cleanupQueue)) {
// 在此作用域内，对象是可达的
System.out.println("Inside try block. Resource is reachable.");
} catch (Exception e) {
e.printStackTrace();
}
// 离开 try-with-resources 块后，res 引用失效
// 此时，如果没有其他强引用指向 new Object()，
// 该对象将成为 GC 的候选者
// 强制 GC 以加速演示过程（生产环境不建议频繁调用）
System.gc();
Thread.sleep(1000); // 给 GC 和清理线程一些时间
monitor.stopMonitoring();
monitor.join();
}
}</phantomresource></object>
在这个示例中，main 方法创建了 PhantomResource 并将其放入 try-with-resources 块。当块结束时，局部变量 res 超出作用域，其对 PhantomResource 的强引用消失。如果 PhantomResource 内部也没有其他强引用指向原始对象（即 resource 字段），那么原始对象就只剩下 PhantomReference 的弱引用。此时，下一次 GC 发生时，原始对象将被回收，PhantomReference 会被推入 refQueue，CleanupMonitor 线程会捕获到这个事件并执行相应的清理逻辑。这种模式特别适用于管理堆外内存、文件句柄或其他需要精确控制生命周期且不希望阻塞主线程的资源。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
