Object.finalize()已被彻底弃用，因执行时机不可靠、拖慢GC、易致死锁与内存泄漏；应改用try-with-resources、Cleaner或显式close()。
Object.finalize() 在现代 Java 开发中已基本退出实用舞台——它不是“慎用”，而是“不该用”。自 Java 9 起被正式
@Deprecated
，到 Java 18 明确标注
，说明 JVM 团队已彻底否定其设计价值。它的存在不再代表一种清理选项，而是一个需要主动规避的历史包袱。
不可靠的执行时机是根本缺陷
finalize() 的调用完全依赖 GC 行为，而 GC 由内存压力、算法策略、JVM 参数等共同决定。这意味着：
对象变成垃圾后，可能数分钟甚至整个程序生命周期内都不会触发 finalize()
程序结束前，GC 可能一次都不运行，导致资源始终未释放
即使触发，也无法保证顺序或线程上下文，不适合协调多个资源的关闭
它会拖慢垃圾回收并引入风险
每个重写了 finalize() 的对象，在被识别为可回收时，不会立即入回收队列，而是先入“finalization queue”，由专用的 Finalizer 线程串行处理。这带来明显问题：
Finalizer 线程若阻塞（如在 finalize 中做 I/O 或等待锁），会卡住整个 finalization 队列，拖慢所有待回收对象的释放
finalize() 内意外让对象“复活”（如将 this 赋给静态变量），会导致对象逃逸，延长生命周期，干扰 GC 判断，甚至引发内存泄漏
抛出的异常会被静默吞掉，错误难以发现和调试
现代替代方案更清晰、可控、可测试
Java 提供了明确、及时、可编程的资源管理机制，完全覆盖 finalize() 曾试图解决的问题：
Eclipse导入Android或其他的JAVA项目的正确方法 WORD版
本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
立即学习
“
Java免费学习笔记（深入）
”；
显式 close() + try-with-resources
：对 Closeable/AutoCloseable 资源（如 FileInputStream、Connection），在作用域结束时确定性关闭，无延迟、无依赖 GC
Cleaner（推荐）
：基于 PhantomReference 实现，不阻止对象回收，也不提供“复活”机会；适合清理 native 内存、映射文件、直接缓冲区等非堆资源（如 DirectByteBuffer 内部就用 Cleaner）
ShutdownHook（谨慎使用）
：仅用于 JVM 退出前的兜底清理，不能替代常规资源管理
遗留代码中遇到 finalize() 怎么办
如果维护老项目，看到重写的 finalize()，优先做三件事：
确认其中逻辑是否真有必要——多数情况只是“习惯性写上”，实际从未被触发或已被其他机制覆盖
将资源释放逻辑提取到 public close() 方法中，并确保所有调用方显式调用
删除 finalize() 方法体，或仅保留
（且建议加注释说明已弃用）
不复杂但容易忽略：finalize() 不是“备用保险”，而是系统性隐患的放大器。现代 Java 的资源契约，建立在开发者主动声明和控制的基础上，而非寄希望于不确定的后台回调。
forRemoval = truesuper.finalize()