finalize方法已被废弃并停用，根本原因在于其设计违背可控、及时、可预测的资源管理原则：执行不可靠、无调用保证、拖慢gc、易致oom及“对象复活”等严重隐患；官方推荐cleaner或显式资源管理替代。
finalize 方法已被现代 JDK 官方废弃并永久停用，根本原因不是它“不够好”，而是它在设计上违背了资源管理的基本原则：**可控、及时、可预测**。它既不能保证执行，也无法满足关键资源释放的时间和可靠性要求，反而会引入严重隐患。
执行完全不可靠，连“是否调用”都无法保障
垃圾回收器不承诺调用 finalize()，哪怕对象已不可达、堆内存持续告急，JVM 也可能跳过它。JDK 9 起标记为 @Deprecated(forRemoval = true)，JDK 18 起默认禁用 Finalizer 线程，JDK 21 中相关逻辑已大幅精简——这不是过渡期警告，而是系统性移除。
- 没有调用时间保证：可能延迟数分钟甚至永不触发
- 没有调用次数保证：某些旧版 JVM 在异常中会重复调用
- 没有线程上下文保证：运行在低优先级的 Finalizer 线程中，无法与业务线程同步
拖慢 GC、引发 OOM，性能代价远超预期
含 finalize 的对象需经历至少两次 GC 周期：第一次仅入队，第二次才真正回收。Finalizer 线程单线程串行处理，无超时、不可中断。一旦某个 finalize() 阻塞（如 IO 等待、死锁），整个队列卡住，后续所有待清理对象堆积，老年代持续膨胀，jstat 显示 pending-finalize 队列长度不断攀升，最终触发 OOM——而此时堆内存可能尚未打满。
语义危险，“对象复活”破坏 GC 根本逻辑
在 finalize() 内将 this 赋值给静态变量或全局集合，会使本该回收的对象重新获得强引用，称为“对象复活”。这直接破坏 JVM 可达性分析基础，导致：
- 同一对象被多次 finalize，资源重复释放（如 close() 被调两次）
- 状态错乱、缓存无限膨胀、内存泄漏难以定位
- Cleaner 等现代方案天然禁止访问原对象，从机制上杜绝此类问题
替代方案成熟且标准，无需任何妥协
官方推荐路径清晰明确：
- 显式关闭 + try-with-resources：适用于实现 AutoCloseable 的资源（文件、连接、流等），作用域结束即释放
- Cleaner（JDK 9+）：基于 PhantomReference，异步、无栈、不阻塞 GC；清理动作与对象解耦，幂等安全
- PhantomReference + ReferenceQueue：仅限框架层精细控制，普通业务应直接使用 Cleaner
重写 finalize() 不是兜底，而是掩盖真实泄漏点——线上几天后 OOM，日志里却找不到哪段代码漏了 close()。
