finalize 是必须避开的历史陷阱，因其调用不可控、拖慢GC、引发对象复活三大隐患；应改用try-with-resources、显式close()或Cleaner进行确定性资源管理。
finalize 方法早已退出实际开发舞台，它不是“备用清理手段”，而是必须避开的历史陷阱。理解它，是为了不踩坑——它的隐患远大于用途，而替代方案清晰、可靠、官方推荐。
finalize 的三大致命隐患
它看似提供“最后一次清理机会”，实则埋下严重风险：
- 调用完全不可控：JVM 不保证执行，也不保证时机。程序退出前可能一次都不调用，文件句柄、数据库连接等资源就一直悬着
- 拖慢并卡死垃圾回收：含 finalize 的对象需经历两次 GC 才能真正回收；Finalizer 线程单线程串行处理，一旦某个 finalize 阻塞（如等待 IO），整个队列积压，老年代持续膨胀，极易触发 OOM
- 引发“对象复活”与状态混乱：在 finalize 中把 this 赋给静态变量，会让本该回收的对象重新可达——不仅破坏 GC 基础逻辑，还可能导致 close() 被重复调用、资源二次释放、缓存错乱
别再用 finalize，改用确定性资源管理
资源释放必须“明确、及时、可预测”。现代 Java 提供了零妥协的替代路径：
- 所有 AutoCloseable 资源一律用 try-with-resources：文件流、网络连接、数据库连接等，离开作用域即自动关闭，编译器保障，无需 GC 参与
- 显式 close() 是责任归属最清晰的方式：尤其在连接池、服务组件等生命周期由业务控制的场景，close() 应作为契约写入接口和文档
- 需要异步延迟清理时，用 Cleaner（非 finalize 替身，而是全新机制）：基于虚引用，不阻塞 GC，清理动作与对象解耦，支持手动 clean() 提前触发，且天然杜绝“访问已回收字段”问题
Cleaner 的正确打开方式
它不是 finalize 的升级版，而是设计哲学不同的新工具——只清理外部资源，不碰 Java 对象状态：
立即学习“Java免费学习笔记（深入）”；
- 声明 static final Cleaner 实例（类级别复用）
- 构造时用 cleaner.register(this, runnable) 绑定清理动作
- 清理函数中只操作底层资源（如 freeMemory、force、close native handle），绝不读取当前对象的字段
- 提供 public close() 方法，内部调用 cleanable.clean()，让使用者掌握主动权
finalize 是一段必须翻过的旧账，而 try-with-resources 和 Cleaner 才是你今天该写的代码。
