Java中应完全避免重写finalize()方法——它已被JDK 18彻底移除，真正风险在于资源未显式释放导致的回收陷阱；现代替代方案是Cleaner或PhantomReference，需配合显式释放与AutoCloseable改造。
Java中应完全避免重写finalize()方法——它不是资源清理的可靠手段，而是已被JDK 18彻底移除的过时机制。真正需要关注的，是对象生命周期中资源未显式释放所埋下的回收陷阱。
Finalize方法本身已失效，风险来自遗留代码与误用惯性
自JDK 9起该方法被标记为@Deprecated，JDK 18正式删除。任何仍在使用它的代码都属于技术债务，而非合规实践。常见误用包括：
- 把
finalize()当作“自动兜底”，替代close()、free()等显式释放逻辑 - 在其中执行IO、锁等待、网络调用等阻塞操作，导致Finalizer线程卡死
- 依赖它保证本地资源（如DirectByteBuffer、文件句柄）一定被清理
- 未检查子类是否调用
super.finalize()，造成父类资源泄漏
变量回收前的真实陷阱：不是“没回收”，而是“无法回收”
很多OOM问题表面看是内存不足，实则是对象因引用链残留而长期滞留。关键不在变量声明，而在引用关系是否被及时切断：
-
静态集合持有对象引用：如
static Map<String, Object> cache不断put却忘了remove或设弱引用 - 内部类隐式持外部类引用：非静态内部类实例生命周期长于外部类时，阻止外部类被回收
-
ThreadLocal未清理：线程复用场景下（如Web容器），ThreadLocal变量若未调用
remove()，会随线程长期存活 - 监听器/回调未注销：GUI事件、Netty ChannelHandler、Spring事件监听器注册后未解绑
现代替代方案：Cleaner比PhantomReference更轻量易用
二者均绕过Finalizer线程，不干扰GC节奏。推荐优先使用Cleaner，除非需精确控制清理时机：
-
Cleaner自动绑定对象生命周期，注册即生效，无需轮询；适合绝大多数资源清理场景 -
PhantomReference必须配合ReferenceQueue主动检测，适合native资源、DirectBuffer等需强管控的场合 - 二者都不允许在清理逻辑中访问被引用对象本身（否则阻碍回收），清理动作应无状态、幂等
排查与迁移：从Finalizer队列到显式终止路径
已有老代码不能直接删finalize()，需分步治理：
- 用
jstack -l <pid>确认是否存在长时间RUNNABLE或BLOCKED的Finalizer线程 - 用
jmap -histo:live <pid>观察堆中java.lang.ref.Finalizer数量是否持续增长 - 定位所有覆盖
finalize()的类，逐个检查其资源是否已在close()/destroy()等方法中显式释放 - 对未覆盖显式释放的类，补全
AutoCloseable接口 + try-with-resources支持，并推动调用方改造
