finalize被废弃因其执行不可控、易致对象复活、拖慢GC且JVM不保证调用；Cleaner基于PhantomReference与专用线程异步清理，解耦生命周期，避免复活与阻塞。
Cleaner 不是 finalize 的“升级版”，而是彻底不同的机制：一个靠 GC 线程被动触发，一个靠专用后台线程主动轮询。
finalize 方法为什么被废弃
它依赖 FinalizerThread，该线程优先级极低，且只在 GC 后才批量处理待终结对象；finalize() 被调用前对象可能被“复活”（比如在方法里重新赋值给静态变量），导致内存泄漏或二次调用风险；JVM 规范不保证调用时机和次数，甚至进程退出时完全不执行。错误现象常见于：日志没输出、连接未关闭、文件句柄泄露，但程序看似正常结束。
Cleaner 如何避免 finalize 的不可靠性
它基于 PhantomReference + ReferenceQueue 实现，由独立的 Cleaner 后台线程监听队列，一旦对象进入虚引用队列就立即触发注册的 Runnable；不参与 GC 主流程，不会造成对象复活；清理逻辑与对象生命周期解耦，更可控。但要注意：Cleaner.create() 返回的实例是全局单例，不应被频繁创建；清理动作必须轻量，否则会阻塞整个 Cleaner 线程，影响其他资源释放。
register 之后对象被提前回收怎么办
如果 cleaner.register(obj, task) 执行前，obj 已不可达（比如刚 new 出来就丢弃引用），Cleanable 会立刻调用 task.run()，但此时你可能还没准备好资源——典型坑点是 native 指针还未初始化完成就触发清理。解决方案包括：
- 确保
obj在register前至少有一个强引用（如赋值给局部变量） - 把资源初始化逻辑放在
register之后，或用双重检查包装 - JDK 17+ 可用带 cleanup key 的重载
register(obj, task, key)，后续通过cleanable.clean()主动取消，避免误触发
System.exit(0) 后 Cleaner 还工作吗
不工作。Cleaner 后台线程不是守护线程（daemon thread），但 JVM 在 System.exit() 或 Runtime.getRuntime().halt() 时会强制终止所有非守护线程，包括 Cleaner 线程。这意味着注册的清理逻辑大概率被跳过。实际部署中，如果服务要优雅关闭，必须显式调用 cleanable.clean() 或封装成 AutoCloseable 在 try-with-resources 中释放，不能依赖进程退出时的自动清理。
真正容易被忽略的是：Cleaner 的线程模型和生命周期管理完全脱离应用主线程控制，它既不响应 shutdown hook，也不受 Spring @PreDestroy 影响——想让它可靠，就得自己握着 Cleanable 实例并主动触发。
