Object.finalize()在现代Java中已被彻底弃用并禁止重写：它执行时机完全不可控、强制对象经历两次GC、阻塞Finalizer线程引发OOM、允许“对象复活”破坏GC语义，JDK 9起@Deprecated(forRemoval=true)，18起默认禁用，21已大幅移除；应改用try-with-resources、Cleaner或PhantomReference分场景替代。
Java 中 Object.finalize() 方法不是“慎用”，而是明确弃用、禁止重写——面试时若只答“它执行不及时”或“性能差”，属于表面理解；高分回答需紧扣 JVM 设计演进、GC 机制本质和现代资源管理范式。
核心缺陷：它违背了资源管理的基本原则
finalize 不是析构函数，也不是兜底保险，而是一个与 GC 强耦合、语义模糊、副作用严重的反模式：
- 时机完全失控：不依赖代码逻辑，只依赖 GC 触发。堆没满、GC 没跑，对象就永远不被终结；程序退出前 GC 可能一次都不发生，资源泄漏无声无息
- 破坏 GC 流程：含 finalize 的对象必须经历两次 GC 周期（标记 → 入 Finalizer 队列 → Finalizer 线程串行执行 → 再标记回收），拖慢吞吐、抬高延迟、加剧内存压力
- 引入严重运行时风险：Finalizer 线程低优先级、无超时、不可中断；一旦某个 finalize 卡在 IO 或锁上，整个队列阻塞，后续所有待终结对象堆积，直接引发 OOM
-
允许“对象复活”：在 finalize 里把
this赋给静态变量，对象重新可达，GC 判断失效，可能重复终结、重复释放、状态错乱，这是 bug 温床，不是特性
为什么 JDK 主动移除，而不是保留兼容？
这不是临时优化，而是架构级否定：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- Java 9 起标记为
@Deprecated(forRemoval = true) - Java 18 默认禁用 Finalizer 线程（通过 JVM 参数间接控制）
- JDK 21 HotSpot 已大幅精简 Finalizer 相关逻辑，仅留最小兼容路径
- JFR（Java Flight Recorder）停止采集 Finalizer 统计，监控工具全面放弃支持
替代方案不是“选一个”，而是分场景落地
面试说到替代，不能只提 Cleaner，要体现工程判断力：
立即学习“Java免费学习笔记（深入）”；
-
绝大多数 I/O 资源（文件、网络、数据库连接）：用
try-with-resources+ 实现AutoCloseable。关闭时机确定、异常可捕获、可测试、符合 Java 标准契约 -
需要异步/延迟清理的 native 或底层资源（如 DirectByteBuffer、自定义内存池）：用
Cleaner（Java 9+）。它基于虚引用，不阻塞 GC，清理动作无法访问原对象，天然杜绝复活 -
极少数需精细控制清理队列或跨线程协调的场景：手动管理
PhantomReference + ReferenceQueue，但需自行处理线程调度与异常，门槛高，非常规选择
如何回答才显深度？
别复述文档，用一句话点透本质：
- “finalize 把资源生命周期交给了 GC 调度器，而现代 Java 要求开发者掌握主动权——资源何时创建、何时释放，必须由业务线程明确驱动。”
- “它曾试图解决‘忘记 close’的问题，结果掩盖了真正的泄漏点；Cleaner 和 try-with-resources 不是功能替代，而是把责任还给了代码本身。”
- “JVM 移除它，不是因为实现不好，而是因为它代表了一种错误的抽象：让不可控的事（GC）去保证可控的事（资源释放）。”
