finalize() 已被废弃，因其不可靠：执行时机不确定、线程不安全、性能差且可能完全不调用；应改用 cleaner 或显式资源管理（如 try-with-resources）。
finalize() 被废弃不是因为写得不好，而是它根本不可靠
Java 9 开始 finalize() 被标记为 @Deprecated(forRemoval = true)，不是建议“少用”，而是明确告诉你：别再依赖它做任何关键逻辑。它的执行时机不确定、线程不安全、性能开销大，且 JVM 可能在任意时刻跳过调用——哪怕对象已不可达。
常见错误现象：finalize() 没被调用，资源泄漏；或被多次调用（某些旧版 JVM 在异常中重入）；又或者在 GC 压力大时集中触发，拖慢整个应用。
- GC 不保证调用
finalize()，甚至可能永远不调用 - 即使调用，也只保证一次，但无法控制在哪个线程、什么时间点
- 每个对象的
finalize()执行会阻塞对应的 Finalizer 线程，容易形成瓶颈 - 子类覆写时若忘记调用
super.finalize()，父类清理逻辑直接丢失
用 Cleaner 替代 finalize() 的正确姿势
Cleaner 是 Java 9 引入的轻量级、线程安全的清理机制，它不依赖对象生命周期，而是绑定一个 Cleanable 实例，由 JVM 在对象不可达后异步触发注册的清理动作。
关键区别在于：清理逻辑和对象解引用解耦，不污染业务类，也不影响 GC 效率。
立即学习“Java免费学习笔记（深入）”；
- 不要在业务类里持有一个
Cleaner静态实例——它本身是线程安全的，全局复用即可 - 注册清理动作时传入的是「被清理对象的弱引用 + 清理函数」，不是 this
- 清理函数必须是无状态、幂等、不能抛出未捕获异常（否则该 cleaner 会被静默禁用）
- 示例：
Cleaner cleaner = Cleaner.create();<br>class ResourceHolder {<br> private final Resource res;<br> private final Cleaner.Cleanable cleanable;<br><br> ResourceHolder() {<br> this.res = new Resource();<br> this.cleanable = cleaner.register(this, res::close); // 注意：res::close 是清理行为<br> }<br>}
守护任务（PhantomReference + ReferenceQueue）还能用吗
能用，但没必要自己手写。除非你在开发框架、需要极细粒度控制（比如监控某类对象存活时长），否则 Cleaner 就是 PhantomReference 的封装增强版，屏蔽了队列轮询、线程调度等复杂细节。
自己用 PhantomReference 容易踩的坑：
- 忘了启动一个后台线程持续
queue.remove()，导致清理永远不发生 - 在
ReferenceQueue处理中调用了被回收对象的方法（此时对象已处于 finalize 状态，字段可能为 null 或已被重写） - 误用
WeakReference或SoftReference替代PhantomReference，它们无法准确感知“即将被回收” - JVM 参数如
-XX:+DisableExplicitGC或 G1 的并发周期策略会影响 reference 处理时机
真正该做的：把清理逻辑移到显式方法 + try-with-resources
绝大多数场景下，finalize() 和 Cleaner 都是兜底手段。你应该优先靠设计规避自动清理需求。
使用场景明确：文件句柄、数据库连接、内存映射区、JNI 分配的本地内存——这些都必须由使用者显式释放。
- 让类实现
AutoCloseable，强制调用方用try-with-resources - 构造函数中不分配关键资源，延迟到首次使用（如 lazy init），降低意外泄漏风险
- 如果真要用
Cleaner，只用于记录告警或打日志（比如“该对象没被 close 就丢了”），而不是替代 close - 注意：
Cleaner的清理函数不能访问对象的非静态字段（对象可能已部分回收），只能操作外部资源或静态上下文
最常被忽略的一点：Cleaner 不解决“谁该负责关闭”的问题，只解决“万一没人关，至少还有个最后机会”。这个“最后机会”本身也可能失败——比如磁盘满导致日志写不进去，或 native 内存已损坏。真正的健壮性来自 API 设计，而不是终结机制。
