Java 的 finalize 方法已被彻底废弃，因执行不确定、拖慢GC、异常静默、支持对象复活且易致资源泄漏；应改用 try-with-resources、Cleaner 或 shutdown hook。
Java 的 finalize 方法已被彻底废弃，不是“不推荐”，而是从机制上不可靠、不安全、不高效，不能用于任何生产环境的资源释放。它早在 Java 9 被标记为 @Deprecated(forRemoval = true)，Java 18 默认禁用 Finalizer 线程，Java 21 中 JVM 不再保证调用，JDK 22 已完全移除相关底层支持。
finalize 为什么被废弃
它不是设计得不够好，而是根本违背了资源管理的基本要求：
-
执行完全不确定：GC 何时运行、是否回收某个对象、是否触发
finalize，全无保障。程序退出前可能一次都不调用 -
严重拖慢垃圾回收：含
finalize的对象必须经历至少两次 GC 才能真正释放——第一次进 Finalizer 队列，第二次才回收。Finalizer 线程是单线程、低优先级、无超时，一旦某个finalize阻塞（比如 IO 等待），整个队列卡住，老年代持续膨胀，极易引发 OOM - 异常被静默吞掉：方法内抛出任何未捕获异常，Finalizer 线程直接终止，后续所有终结逻辑停摆，且无日志、无告警
-
支持“对象复活”，破坏 GC 基础：在
finalize中把this赋给静态引用，对象会逃过本次回收，下次又进队列——导致重复清理、状态错乱、缓存泄漏等隐蔽问题 -
子类重写易遗漏父类逻辑：若忘记调用
super.finalize()，父类的清理动作就永久丢失
资源释放的正确做法：按场景选方案
现代 Java 不提供“通用终结器”，而是根据资源类型提供确定性、可监控、可超时的释放路径：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
所有实现了
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()，但仅限真正无法提前释放的全局性操作，不可替代常规资源管理
绝对要避免的写法
以下代码无论多“简洁”，都属于高危反模式，应立即从代码库中清除：
立即学习“Java免费学习笔记（深入）”；
- 重写
finalize()并在里面调用close()或释放资源 - 声明空的
finalize()方法（哪怕只有一行super.finalize();）——它仍会让对象进入 Finalizer 队列，带来性能惩罚 - 把
finalize当作“析构函数”或“最后保险”，认为“万一忘了 close，还有它兜底” - 在面试或设计文档中将
finalize列为“备选方案”
