finalize 方法已被官方废弃，因其违背资源管理原则：执行时机不可控、行为不可靠、代价过高；它依赖gc触发、可能永不调用、拖慢回收效率、引发oom，并允许危险的“对象复活”；应改用autocloseable+try-with-resources或cleaner等可靠替代方案。
finalize 方法已被现代 JDK 官方废弃，根本原因不是它“不好用”，而是它违背了资源管理的基本原则：时机不可控、行为不可靠、代价不可接受。
执行完全不可预测，无法用于关键清理
垃圾回收器不保证调用 finalize()，甚至可能永远不调用。它依赖 GC 触发时机——堆内存压力、算法策略、JVM 参数都会影响。一个持有文件句柄的对象，可能在程序运行数小时后才被回收，期间句柄持续泄漏。更严重的是，JVM 只保证最多调用一次，但不保证在哪个线程、什么时间点执行，也无法监控是否成功完成。
拖慢 GC 效率，引发连锁 OOM 风险
重写 finalize() 的对象会被 JVM 特殊对待：必须经历至少两次 GC 周期才能真正释放——第一次标记并入 Finalizer 队列，第二次才回收内存。这直接导致回收延迟数十倍。Finalizer 线程是单线程、低优先级、无超时机制，一旦某个 finalize() 里发生阻塞（如网络等待、锁竞争），整个队列就会卡住，待处理对象越积越多，老年代持续膨胀，最终触发 OutOfMemoryError，而此时堆内存可能尚未真正满载。
语义危险，“对象复活”破坏 GC 正确性
在 finalize() 中将 this 赋值给静态变量或全局集合，会让本该被回收的对象重新获得强引用，这就是“对象复活”。它不仅让 GC 的可达性分析失效，还可能导致同一对象被多次 finalize，引发重复关闭资源、状态错乱甚至崩溃。这种行为不是设计特性，而是严重 bug 温床，且难以排查。
替代方案成熟可靠，无需妥协
现代 Java 提供了明确、可控、可监控的替代路径：
- 对需手动释放的资源（如流、通道、连接），优先实现 AutoCloseable 并配合 try-with-resources 使用；
- 需要异步清理且不依赖对象实例时，使用 Cleaner（JDK 9+），它基于虚引用，不阻塞 GC，清理动作与对象解耦；
- 避免继承式清理逻辑，不重写 finalize()，也不依赖 Runtime.runFinalizersOnExit（早已废弃）；
- 把资源释放视为业务责任，而非“等 GC 来救火”——用完即关，才是稳定系统的基石。
