如何在 Java 中利用 PhantomReference 配合引用队列实现对象被回收后的清理逻辑-java教程-PHP中文网

phantomreference必须搭配referencequeue使用，因其get()恒返回null，无法访问对象，且仅入队后才通知回收完成；不配队列则完全无法感知回收事件，清理逻辑无法触发。

如何在 java 中利用 phantomreference 配合引用队列实现对象被回收后的清理逻辑

PhantomReference 为什么必须搭配 ReferenceQueue 使用

因为 PhantomReference 的 get() 方法永远返回 null，你无法通过它访问被引用对象——设计上就禁止了。不配 ReferenceQueue，你就完全收不到对象被回收的通知，清理逻辑根本无从触发。

常见错误是只 new 出 PhantomReference 就扔一边，结果对象明明已不可达、GC 也发生了，但你的清理代码一动不动。这是因为没有队列，JVM 不会把该引用入队，也就没机会轮询或阻塞等待。

必须在构造时传入非 null 的 ReferenceQueue
队列类型要和引用类型匹配：ReferenceQueue<object></object> 即可，不用泛型擦除后硬写 ReferenceQueue
不要试图调用 phantomRef.get() 拿对象——它一定为 null，这是规范行为，不是 bug

如何安全地轮询 ReferenceQueue 触发清理

不能直接在 GC 后“立刻”做清理，得靠轮询或阻塞获取已入队的 PhantomReference 实例。注意：入队发生在对象内存被真正回收之后（即 finalize() 已执行完，且对象不可复活），此时对象实例已不可访问，但你可以用引用本身携带的元数据做清理。

典型做法是启一个单独线程持续 queue.remove()，但要注意：

remove() 是阻塞的，如果队列为空会一直等下去，适合后台守护线程
若不想阻塞，可用 poll() 配合短时 sleep，避免空转耗 CPU
每次拿到 PhantomReference 后，应立即调用 clear()，防止重复处理（虽然入队只发生一次，但多线程下保险起见）
别在清理逻辑里再强引用原对象——它已经不可达，且可能已被回收；所有必要信息应在创建 PhantomReference 时通过子类或闭包捕获

示例关键片段：

Gradle 9.8.0

下载

class CleanableReference extends PhantomReference<object> {
    private final Runnable cleanup;
    CleanableReference(Object referent, ReferenceQueue super Object> q, Runnable cleanup) {
        super(referent, q);
        this.cleanup = cleanup;
    }
    void cleanup() { this.cleanup.run(); }
}

// 启动清理线程
Thread cleaner = new Thread(() -> {
    while (!Thread.currentThread().isInterrupted()) {
        try {
            CleanableReference ref = (CleanableReference) queue.remove();
            ref.cleanup();
            ref.clear(); // 显式清空，便于 GC 回收引用自身
        } catch (InterruptedException e) {
            break;
        }
    }
});
cleaner.setDaemon(true);
cleaner.start();</object>

为什么不能用 finalize() 或 Cleaner 替代

finalize() 已被标记为 deprecated，执行时机不确定、性能差、可能被多次调用（如果复活）、且不保证执行——JVM 可能直接跳过。而 Cleaner（Java 9+）本质就是对 PhantomReference + ReferenceQueue 的封装，更易用但底层一样。

如果你用的是 Java 9+，优先选 Cleaner；但一旦需要精细控制（比如复用队列、自定义清理线程策略、或兼容老版本），就必须直操作 PhantomReference。