Java对象在new指令执行时真正创建，此时完成内存分配、默认初始化及类初始化（若未完成），构造函数调用在其后；构造异常不改变已分配事实，仅不返回引用。
Java对象什么时候真正被创建
对象在 new 指令执行时才分配内存并初始化，但前提是类已加载、验证、准备、解析（即完成类加载的前四步）。如果类尚未初始化，new 会触发类的初始化（执行 <clinit></clinit> 方法），这可能隐含静态字段赋值、静态代码块执行等副作用。
常见误区是认为构造函数执行才算“创建完成”——其实构造函数是在内存分配和默认初始化（如 int 设为 0、引用设为 null）之后才调用的。若构造函数抛出异常，对象仍算“已创建过”，只是没有成功返回引用，JVM 会清理栈帧，但堆中已分配的内存需等待 GC。
- 使用
Unsafe.allocateInstance()可绕过构造函数分配对象（不推荐，破坏封装且不触发初始化） - 反射
Constructor.newInstance()和new在字节码层面都生成new+invokespecial，但前者多一层安全检查和参数包装开销 - 对象头中的
Mark Word在分配时就写入锁状态、GC分代年龄等元信息，不是构造后才填
对象何时进入老年代：不只是“活过15次GC”
年轻代对象晋升老年代有多个条件，并发 GC（如 G1、ZGC）下规则更复杂。CMS 和 Parallel GC 中，MaxTenuringThreshold 默认为 15，但实际晋升可能早于该阈值：
- Survivor 空间不足时，部分对象直接“担保失败”（promotion failure），提前进入老年代
-
PretenureSizeThreshold设置后，大于该值的大对象（如大数组）直接在老年代分配（仅限 Serial / Parallel GC；G1 中由G1HeapRegionSize和 humongous 对象逻辑控制） - G1 中，如果 Survivor 区复制后依然拥挤，或预测下次 GC 无法容纳存活对象，会提前触发混合回收（Mixed GC），并调整晋升策略
验证方式：添加 -XX:+PrintGCDetails -Xlog:gc+age=debug（JDK 10+）可看到每次 GC 后各年龄对象大小分布。
立即学习“Java免费学习笔记（深入）”；
finalize() 已被废弃，但对象的“临终回调”还有替代方案
finalize() 自 JDK 9 起标记为 @Deprecated，JDK 18 彻底移除。它不可靠（不保证何时执行、是否执行）、性能差（拖慢 GC）、易导致对象复活（resurrection），且与现代 GC 算法（如 ZGC 的无停顿设计）冲突。
替代方案应按优先级选择：
- 实现
AutoCloseable，配合 try-with-resources —— 适用于明确生命周期边界的资源（文件、连接） - 使用
Cleaner（JDK 9+）：基于虚引用（PhantomReference）和 CleanerThread，无复活风险，可注册清理动作，例如：private static final Cleaner cleaner = Cleaner.create(); private final Cleaner.Cleanable cleanable; public MyClass(File f) { this.file = f; this.cleanable = cleaner.register(this, new CleanupAction(f)); } - 避免依赖任何“自动”回调，改用显式 shutdown 或 close 配合监控告警（如 Netty 的
EventLoopGroup.shutdownGracefully()）
对象可达性判断不是简单的“有引用就没回收”
JVM 判断对象是否可回收，依据的是 GC Roots 的**可达性分析**，而非引用计数。即使对象被强引用指向，只要该引用本身不可达（如局部变量已出作用域、线程结束、静态引用被置为 null），对象就可能被回收。
容易忽略的关键点：
- 方法栈帧中局部变量表的引用，在方法退出后立即失效，哪怕对象还在堆中 —— 不需要等到整个线程结束
- 软引用（
SoftReference）只在内存不足时被回收，适合缓存；弱引用（WeakReference）在下一次 GC 就回收，适合 canonicalizing map（如WeakHashMap） - 虚引用（
PhantomReference）无法通过它获取对象实例，仅用于跟踪对象被回收的时间点，必须配合ReferenceQueue - JNI 全局引用（
GlobalRef）会阻止 Java 对象被回收，需手动DeleteGlobalRef，否则造成内存泄漏
调试建议：用 jmap -histo:live <pid> 查看当前存活对象统计，结合 jstack 分析线程栈，确认 GC Roots 路径是否意外持有了不该持有的对象。
