finalize方法自Java 9起被弃用，不可靠且禁用于关键资源释放；Cleaner基于虚引用和守护线程，提供更可控的异步清理机制，推荐配合显式close使用。
Java 中 finalize 方法早已被弃用（自 Java 9 标记为 @Deprecated(forRemoval = true)），它不可靠、性能差、无法保证执行时机，**绝不能用于关键资源释放**。替代方案中，Cleaner 是官方推荐的轻量级、可预测的清理机制，适用于管理堆外内存、文件句柄、Socket 连接等外部资源。
为什么 Cleaner 比 finalize 更可靠
Cleaner 基于虚引用（PhantomReference）和后台守护线程，不阻塞 GC，也不影响对象生命周期判断。它在对象被 GC 回收后，由 Cleaner 线程异步调用注册的清理动作——这个时机虽仍不绝对实时，但比 finalize 可控得多，且无同步开销和死锁风险。
使用 Cleaner 管理外部资源的基本步骤
以封装一个需要显式关闭的本地文件句柄（模拟）为例：
- 定义一个持有资源的类，并持有一个 Cleaner 实例和 cleanable 引用：Cleaner 是静态共享的，cleanable 是绑定当前对象与清理动作的桥梁。
- 在构造时注册清理动作：传入一个 Runnable，其中执行 close()、free() 等释放逻辑；该 Runnable 不得访问原对象的任何字段（因对象可能已部分回收）。
- 提供显式的 close() 方法（强烈建议）：让使用者能主动释放资源，避免等待 GC；close 内部应取消 cleanable 注册（避免重复清理）并执行实际释放。
代码示例：用 Cleaner 管理模拟的本地资源
// 示例：管理一个需要手动释放的 long 类型资源 ID（如 mmap 地址或 native handle）
立即学习“Java免费学习笔记（深入）”；
public class ManagedResource {
private static final Cleaner cleaner = Cleaner.create();
// 模拟外部资源标识
private final long resourceId;
// 清理动作的持有者（虚引用关联点）
private final Cleanable cleanable;
public ManagedResource(long resourceId) {
this.resourceId = resourceId;
// 注册清理动作：仅使用 resourceId，不捕获 this
this.cleanable = cleaner.register(this, new ResourceCleanup(resourceId));
}
// 显式关闭 —— 推荐的最佳实践
public void close() {
cleanable.clean(); // 主动触发清理，并自动注销
}
// 清理逻辑必须是静态/无状态的，避免引用 this
private static class ResourceCleanup implements Runnable {
private final long resourceId;
ResourceCleanup(long resourceId) {
this.resourceId = resourceId;
}
@Override
public void run() {
System.out.println("Releasing resource: " + resourceId);
// 调用 JNI free、CloseHandle、munmap 等
// nativeFree(resourceId);
}
}
}
使用时：
ManagedResource r = new ManagedResource(0x12345L); // ... 使用 r r.close(); // ✅ 主动释放 // 或者不调用 close，等 GC 后 Cleaner 自动清理（不推荐依赖此路径）
注意事项和常见陷阱
- 不要在 Runnable 中访问原始对象字段或方法：此时对象可能已被回收，字段值不确定，甚至引发 NullPointerException。
- Cleaner 线程不保证立即执行：它依赖 GC 触发，仍有延迟；对实时性要求高的场景（如数据库连接池），仍需配合 try-with-resources 和显式 close。
- 每个 Cleaner 实例会启动一个守护线程：通常复用同一个 Cleaner（如类静态变量），不要为每个对象创建新 Cleaner。
-
无法替代 try-with-resources：Cleaner 是兜底机制，不是资源管理主逻辑；实现
AutoCloseable并鼓励用户用 try-with-resources 才是正解。
