Java 对象的 `finalize` 方法为什么被废弃以及怎么处理资源释放-java教程-PHP中文网

java 的 finalize 方法已被彻底废弃，因执行不确定、拖慢gc、异常静默、支持对象复活且易致资源泄漏；应改用 try-with-resources、cleaner 或 shutdown hook。

java 对象的 `finalize` 方法为什么被废弃以及怎么处理资源释放

Java 的 finalize 方法已被彻底废弃，不是“不推荐”，而是从机制上不可靠、不安全、不高效，不能用于任何生产环境的资源释放。它早在 Java 9 被标记为 @Deprecated(forRemoval = true)，Java 18 默认禁用 Finalizer 线程，Java 21 中 JVM 不再保证调用，JDK 22 已完全移除相关底层支持。

finalize 为什么被废弃

它不是设计得不够好，而是根本违背了资源管理的基本要求：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

执行完全不确定：GC 何时运行、是否回收某个对象、是否触发 finalize，全无保障。程序退出前可能一次都不调用
严重拖慢垃圾回收：含 finalize 的对象必须经历至少两次 GC 才能真正释放——第一次进 Finalizer 队列，第二次才回收。Finalizer 线程是单线程、低优先级、无超时，一旦某个 finalize 阻塞（比如 IO 等待），整个队列卡住，老年代持续膨胀，极易引发 OOM
异常被静默吞掉：方法内抛出任何未捕获异常，Finalizer 线程直接终止，后续所有终结逻辑停摆，且无日志、无告警
支持“对象复活”，破坏 GC 基础：在 finalize 中把 this 赋给静态引用，对象会逃过本次回收，下次又进队列——导致重复清理、状态错乱、缓存泄漏等隐蔽问题
子类重写易遗漏父类逻辑：若忘记调用 super.finalize()，父类的清理动作就永久丢失

资源释放的正确做法：按场景选方案

现代 Java 不提供“通用终结器”，而是根据资源类型提供确定性、可监控、可超时的释放路径：

所有实现了 AutoCloseable 的资源（文件、流、数据库连接、网络套接字）：必须用 try-with-resources
try (FileInputStream fis = new FileInputStream("data.txt");
BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) {
// 使用资源
}
编译器自动插入 close() 调用，作用域结束即释放，不依赖 GC，不引入额外线程
非堆资源（如 DirectByteBuffer、MappedByteBuffer、本地句柄、JNI 分配内存）：使用 Cleaner（Java 9+）
它基于虚引用（PhantomReference），注册清理动作时不持有强引用，不阻塞 GC，不支持对象复活，天然线程安全，且可配合 Cleaner.Cleanable 实现幂等清理
极少数需要 JVM 退出时兜底的场景（如日志刷盘、临时文件清理）：用 Runtime.addShutdownHook()，但仅限真正无法提前释放的全局性操作，不可替代常规资源管理