不建议重写finalize方法，因其自java 9起被弃用、调用不可靠，易致内存泄漏；应改用try-with-resources、cleaner或弱引用等确定性资源管理机制。

Java 中不建议重写 finalize 方法来避免内存泄漏，因为该方法本身已被弃用，且无法可靠防止内存泄漏。

finalize 方法早已被弃用

自 Java 9 起，finalize 方法被标记为 @Deprecated(forRemoval = true)，Java 18 开始默认禁用它。JVM 不保证该方法会被调用，也不保证调用时机，甚至可能完全不调用。依赖它释放资源或清理引用，极易导致资源泄露、对象长期驻留堆中，反而加剧内存问题。

真正有效的替代方案

应使用现代、确定性的资源管理机制：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 显式关闭资源：实现 AutoCloseable，配合 try-with-resources 自动调用 close()
• Cleaner（推荐）：Java 9 引入的轻量级、非阻塞的清理工具，比 finalize 更可控、更安全。例如：
  

  Cleaner cleaner = Cleaner.create();<br>
  cleaner.register(obj, new CleanupAction());

• 弱引用/软引用 + 引用队列：适用于缓存、监听器解注册等场景，配合手动清理逻辑

为什么重写 finalize 反而增加泄漏风险

重写 finalize 容易引入以下隐患：

• 在 finalize 中重新使对象“复活”（如将 this 赋值给静态字段），导致对象无法被回收，且仅能被回收一次
• 执行时间不可控，可能拖慢 GC，堆积大量待终结对象，引发 OutOfMemoryError
• 无法处理循环引用或未显式释放的本地资源（如文件句柄、Socket）

检查和修复内存泄漏的正确做法

不要寄希望于 finalize，而应聚焦于主动治理：

• 使用 VisualVM、JProfiler 或 Java Mission Control 分析堆快照，定位长生命周期对象及其引用链
• 检查静态集合（如 static Map）是否无限制缓存对象，未及时移除
• 确认监听器、回调、线程本地变量（ThreadLocal）是否已正确清理
• 对持有外部资源的对象，统一通过 close() 或 shutdown() 显式释放

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南