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：
立即学习“Java免费学习笔记（深入）”；
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<string> cache = new ArrayList();</string>）长期持有对象引用，造成内存泄漏 - ThreadLocal 变量未调用
remove()，导致线程结束时对象仍被持有（尤其在线程池中） - 内部类隐式持有外部类引用，若内部类对象生命周期长于外部类，会阻止外部类回收
System.gc() 是建议而非指令，多数情况下应忽略
调用 System.gc() 仅向 JVM 发出“建议”执行 Full GC，但 HotSpot 默认忽略该请求（除非启动参数加 -XX:+ExplicitGCInvokesConcurrent）。生产环境主动调用它，往往掩盖了真正的内存问题，还可能引发 STW 暂停。
真正需要干预 GC 的情况极少，更合理的做法是：
- 用
jstat -gc <pid></pid>观察 GC 频率与停顿时间 - 用
-Xlog:gc*:file=gc.log开启 GC 日志，定位晋升失败（Promotion Failure）或元空间溢出（Metaspace OOM） - 调整堆大小或 GC 策略（如从 Parallel 改为 G1）前，先确认是对象分配速率过高，还是内存泄漏
对象生命周期管理的核心不在“怎么杀”，而在“谁在持有着它”。排查时优先检查引用链，而不是盯着构造和 finalize。
