Java对象在new指令执行时真正创建,此时完成内存分配、默认初始化及类初始化(若未完成),构造函数调用在其后;构造异常不改变已分配事实,仅不返回引用。

Java对象什么时候真正被创建
对象在 new 指令执行时才分配内存并初始化,但前提是类已加载、验证、准备、解析(即完成类加载的前四步)。如果类尚未初始化,new 会触发类的初始化(执行 方法),这可能隐含静态字段赋值、静态代码块执行等副作用。
常见误区是认为构造函数执行才算“创建完成”——其实构造函数是在内存分配和默认初始化(如 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 查看当前存活对象统计,结合 jstack 分析线程栈,确认 GC Roots 路径是否意外持有了不该持有的对象。










