java 垃圾回收中，cleaner 通过实现 java.lang.ref.cleaner 接口来替代 finalize()。具体做法是创建一个继承自 phantomreference 的引用类，并在其中注册一个实现了 runnable 接口的清理任务到 cleaner 实例上。当对象被 gc 判定为不可达时，gc 线程会将该引用加入队列，随后 cleaner 的守护线程会执行注册的清理逻辑并移除引用。与 finalize() 相比，这种方式避免了对象复活的风险，且能更可靠地释放堆外资源。
如何定义可清理的对象引用
要使用 Cleaner，首先需要定义一个持有堆外资源的类，并创建一个对应的“幽灵引用”类。这个引用类必须继承自 PhantomReference，并将目标对象作为构造参数传入。在构造函数中，调用 Cleaner.create() 获取全局的 Cleaner 实例，然后调用其 register() 方法，将当前引用对象和一个执行清理操作的 Runnable 任务绑定。这样，当目标对象失去强引用并被 GC 回收后，GC 线程会将这个 PhantomReference 放入引用队列，触发后续的清理流程。
import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;
import sun.misc.Cleaner;
public class NativeResource {
private long address;
private final Cleaner cleaner;
public NativeResource() {
this.address = allocateNativeMemory();
// 创建幽灵引用并注册清理器
this.cleaner = Cleaner.create();
this.cleaner.register(this, new CleanupTask());
}
private long allocateNativeMemory() {
return 0x1000; // 模拟分配地址
}
private class CleanupTask implements Runnable {
@Override
public void run() {
if (address != 0) {
System.out.println("Releasing native memory at: " + Long.toHexString(address));
address = 0;
}
}
}
}上述代码展示了核心结构。注意 Cleaner 是 JDK 内部 API（sun.misc），在生产环境中通常建议使用 jdk.internal.ref.Cleaner 或通过反射访问，但为了演示原理，这里直接使用标准库中常见的内部类路径。实际开发中，建议将 CleanupTask 提取为静态内部类或独立类，以避免闭包带来的潜在内存泄漏风险。
Cleaner 的执行机制与优势
Cleaner 的执行依赖于 JVM 内部的引用处理线程。当对象被回收时，GC 线程会将 PhantomReference 入队，随后 Cleaner 的守护线程从队列中取出引用，执行绑定的 run() 方法。这一过程是异步的，且不保证立即执行。相比 finalize()，Cleaner 的主要优势在于：第一，它不会导致对象复活，因为 PhantomReference 的 get() 方法始终返回 null；第二，它提供了明确的清理契约，开发者可以确保资源在不再使用时被释放，而不是依赖不确定的 finalize 时机；第三，它支持多次注册，但通常只执行一次清理任务，避免重复操作。
立即学习“Java免费学习笔记（深入）”；
import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;
import sun.misc.Cleaner;
public class TestCleaner {
public static void main(String[] args) {
NativeResource resource = new NativeResource();
resource = null; // 断开强引用
System.gc(); // 触发 GC
try { Thread.sleep(100); } catch (InterruptedException e) {}
System.out.println("Cleanup completed.");
}
}运行上述测试程序，控制台将输出清理任务的日志，证明 Cleaner 成功执行了资源释放。需要注意的是，System.gc() 仅建议用于测试，生产环境中应依赖 JVM 自动调度。此外，由于 Cleaner 是守护线程，JVM 退出时可能不会等待所有清理任务完成，因此对于关键资源，仍需结合 try-with-resources 或显式关闭方法进行兜底。
Cleaner 在 NIO ByteBuffer 中的实际应用
在 Java NIO 中，ByteBuffer.allocateDirect() 创建的直接缓冲区就是 Cleaner 的典型应用场景。该类内部维护了一个 Cleaner 实例，并在构造时注册了清理任务。当 ByteBuffer 对象被 GC 回收时，Cleaner 会自动调用 Unsafe.freeMemory() 释放底层堆外内存。这种设计确保了即使开发者忘记手动释放资源，也不会导致内存泄漏。然而，由于 Cleaner 的异步特性，如果程序在短时间内大量创建和丢弃直接缓冲区，可能会因清理延迟而导致瞬时内存压力。因此，在高并发场景下，建议复用缓冲区或使用池化技术，以减少 GC 压力和清理开销。
