现代 Java 中 Object.finalize() 的作用和重要性如何体现？

本文共计893个文字，预计阅读时间需要4分钟。

`Object.finalize()` 在现代 Java 开发中已基本退出舞台——它不再是不推荐使用，而是不应当使用。自 Java 9 开始，该方法被正式标记为 `@Deprecated`，到 Java 18 时，明确标注 `forRemoval=true`，表明 JVM 团队已决定不再支持其设计价值。

它的存在不再代表一种清理选项，而是一个需要主动规避的历史遗留问题。

不可靠的执行时机是根本缺陷

finalize() 的调用完全依赖 GC 行为，而 GC 由内存压力、算法策略、JVM 参数等共同决定。这意味着：

• 对象变成垃圾后，可能数分钟甚至整个程序生命周期内都不会触发 finalize()
• 程序结束前，GC 可能一次都不运行，导致资源始终未释放
• 即使触发，也无法保证顺序或线程上下文，不适合协调多个资源的关闭

它会拖慢垃圾回收并引入风险

每个重写了 finalize() 的对象，在被识别为可回收时，不会立即入回收队列，而是先入“finalization queue”，由专用的 Finalizer 线程串行处理。这带来明显问题：

• Finalizer 线程若阻塞（如在 finalize 中做 I/O 或等待锁），会卡住整个 finalization 队列，拖慢所有待回收对象的释放
• finalize() 内意外让对象“复活”（如将 this 赋给静态变量），会导致对象逃逸，延长生命周期，干扰 GC 判断，甚至引发内存泄漏
• 抛出的异常会被静默吞掉，错误难以发现和调试

现代替代方案更清晰、可控、可测试

Java 提供了明确、及时、可编程的资源管理机制，完全覆盖 finalize() 曾试图解决的问题：

立即学习“Java免费学习笔记（深入）”；

• 显式 close() + try-with-resources：对 Closeable/AutoCloseable 资源（如 FileInputStream、Connection），在作用域结束时确定性关闭，无延迟、无依赖 GC
• Cleaner（推荐）：基于 PhantomReference 实现，不阻止对象回收，也不提供“复活”机会；适合清理 native 内存、映射文件、直接缓冲区等非堆资源（如 DirectByteBuffer 内部就用 Cleaner）
• ShutdownHook（谨慎使用）：仅用于 JVM 退出前的兜底清理，不能替代常规资源管理

遗留代码中遇到 finalize() 怎么办

如果维护老项目，看到重写的 finalize()，优先做三件事：

• 确认其中逻辑是否真有必要——多数情况只是“习惯性写上”，实际从未被触发或已被其他机制覆盖
• 将资源释放逻辑提取到 public close() 方法中，并确保所有调用方显式调用
• 删除 finalize() 方法体，或仅保留 super.finalize()（且建议加注释说明已弃用）

不复杂但容易忽略：finalize() 不是“备用保险”，而是系统性隐患的放大器。现代 Java 的资源契约，建立在开发者主动声明和控制的基础上，而非寄希望于不确定的后台回调。