Java对象销毁由JVM垃圾回收器自动完成，需经可达性判定（是否被GC Roots引用）、finalize()（已弃用）及内存回收（标记-清除/复制/整理）三阶段，非程序员主动触发且无固定时间点。

Java 对象的销毁不是程序员主动触发的操作，而是由 JVM 的垃圾回收器（GC）在后台自动完成的。它不等于“调用某个方法就立刻消失”，而是一个包含可达性判定、回收准备和内存释放的渐进过程。

对象什么时候算“可销毁”

关键看是否还被任何 GC Roots 引用：

• 虚拟机栈中正在使用的局部变量（比如方法里的 Object obj = new Object() 中的 obj）
• 方法区中类的静态字段（static Object cache）
• 常量池中的字符串常量或类引用
• 本地方法栈中 JNI 持有的对象引用

只要从这些根节点出发，没有任何引用链能到达该对象，它就被判定为“不可达”，成为垃圾候选者。

销毁前可能触发 finalize()（但基本不用）

finalize() 是 Object 类定义的方法，JVM 在真正回收前最多调用一次。但它有严重缺陷：

立即学习“Java免费学习笔记（深入）”；

Java注释规范Skills

当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。

下载

• 执行时间完全不确定——GC 何时运行、是否运行、是否立即执行 finalize 都不可控
• 不能保证一定会被调用（比如程序退出前 GC 没触发）
• 性能开销大，还会拖慢回收流程
• 已被标记为 @Deprecated（自 Java 9 起），官方明确不推荐用于资源清理

替代方案是使用 try-with-resources 或显式 close()，或者 Cleaner（Java 9+ 推荐）。

真正销毁：内存回收与空间整理

一旦对象被确认为垃圾，GC 会根据所用收集器（如 G1、ZGC）和堆内存区域（年轻代/老年代），采用对应算法回收：

• 标记-清除：先标记所有存活对象，再清除未标记部分（可能产生碎片）
• 复制算法（年轻代常用）：把存活对象复制到另一块区域，原区域整块清空
• 标记-整理（老年代常用）：标记后将存活对象向一端压缩，再清理边界外内存

这个阶段完成后，对象占用的堆内存才真正归还给 JVM，可供后续新对象分配使用。

销毁不是“瞬间消失”，而是“逐步失效”

整个过程没有固定时间点：

• 你把引用设为 null 或方法结束，只是让对象“失去可达性”，不是销毁
• GC 是否运行、何时运行、是否选中该对象，取决于堆压力、收集器策略和 JVM 参数
• 对象可能在不可达后数秒、数分钟甚至更久才被真正回收（尤其在内存充足时）

所以，不能依赖销毁时机做业务逻辑，只能确保引用及时释放、资源显式关闭。