Java对象的创建与销毁机制_技术教程

Java中new触发类加载、堆分配、默认初始化、构造器执行；对象销毁需满足无GC Roots可达、被判定不可达且经GC标记，非立即回收。

new 关键字触发的内存分配与初始化流程

Java 中 new 不只是语法糖，它会依次触发类加载（若未加载）、堆内存分配、默认字段初始化、构造器执行。关键点在于：对象实际在堆上分配，但 JIT 可能通过逃逸分析做栈上分配优化（对开发者透明，但影响 GC 压力）。

常见误区是认为 new 后立即“可用”——其实若构造器抛异常（如 NullPointerException 或自定义异常），对象创建就失败，JVM 会清理已分配内存，不会留下半初始化对象。

构造器中避免调用可被子类重写的方法（可能访问到未初始化的字段）
静态工厂方法（如 LocalDateTime.now()）比直接 new 更灵活，也便于返回缓存实例或子类
大量短生命周期对象（如循环内 new String()）会快速填充年轻代，触发 Minor GC

finalize() 已被废弃，替代方案是 Cleaner 和 PhantomReference

finalize() 自 Java 9 起标记为 @Deprecated，Java 18 彻底移除。它不可靠（不保证何时执行、甚至不保证执行）、性能差、易导致对象复活（resurrection），且与现代 GC 算法（如 ZGC、Shenandoah）不兼容。

真正需要资源清理（如关闭文件句柄、释放 JNI 内存）时，应优先使用 try-with-resources；若必须异步清理，用 Cleaner：

private static final Cleaner cleaner = Cleaner.create();
private static class State implements Runnable {
    private final FileDescriptor fd;
    State(FileDescriptor fd) { this.fd = fd; }
    public void run() { close(fd); }
}
private final Cleaner.Cleanable cleanable;
public Resource(FileDescriptor fd) {
    this.cleanable = cleaner.register(this, new State(fd));
}

Cleaner 基于 PhantomReference，不阻止 GC，无复活风险
不要在 Cleaner 的 run() 中执行耗时操作（如网络调用），它运行在专用线程池中
显式调用 cleanable.clean() 可提前触发清理，适用于确定性释放场景

对象何时真正“销毁”：GC 回收的三个必要条件

对象被回收不是因为“不再使用”，而是满足三个条件：没有 GC Roots 可达路径、被判定为不可达、且经过至少一次 GC 标记阶段（取决于 GC 算法）。即使满足，也不代表立即回收——ZGC 的回收是并发的，G1 的 Mixed GC 是分批次的。

典型误判场景：

静态集合（如 public static List cache = new ArrayList();）长期持有对象引用，造成内存泄漏
ThreadLocal 变量未调用 remove()，导致线程结束时对象仍被持有（尤其在线程池中）
内部类隐式持有外部类引用，若内部类对象生命周期长于外部类，会阻止外部类回收

System.gc() 是建议而非指令，多数情况下应忽略

调用 System.gc() 仅向 JVM 发出“建议”执行 Full GC，但 HotSpot 默认忽略该请求（除非启动参数加 -XX:+ExplicitGCInvokesConcurrent）。生产环境主动调用它，往往掩盖了真正的内存问题，还可能引发 STW 暂停。

真正需要干预 GC 的情况极少，更合理的做法是：

用 jstat -gc 观察 GC 频率与停顿时间
用 -Xlog:gc*:file=gc.log 开启 GC 日志，定位晋升失败（Promotion Failure）或元空间溢出（Metaspace OOM）
调整堆大小或 GC 策略（如从 Parallel 改为 G1）前，先确认是对象分配速率过高，还是内存泄漏

对象生命周期管理的核心不在“怎么杀”，而在“谁在持有着它”。排查时优先检查引用链，而不是盯着构造和 finalize。