Object.finalize()已被彻底弃用，因执行时机不可靠、拖慢GC、易致死锁与内存泄漏；应改用try-with-resources、Cleaner或显式close()。
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 的资源契约，建立在开发者主动声明和控制的基础上，而非寄希望于不确定的后台回调。
