Java中的对象终结机制finalize()为什么被废弃_Cleaner与守护任务替代

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