new关键字创建对象时先触发类加载五阶段,待执行完毕才分配内存并调用;对象内存布局含对象头、实例数据、对齐填充;finalize已废弃,推荐Cleaner;GC Roots包括栈变量、静态属性、常量、JNI引用及被锁对象。

new 关键字触发类加载与构造执行
Java 中绝大多数对象通过 new 创建,但这不是简单分配内存——它会隐式触发类加载(如果类未初始化)、验证、准备、解析、初始化五个阶段。只有当类的 方法执行完毕,new 才真正开始为对象分配堆内存,并调用 (即你写的构造方法)。
常见误区是认为 new 只做“分配+初始化”,其实它依赖完整的类初始化流程。例如访问一个尚未加载的类的静态字段,也会提前触发类初始化,此时若构造器里又引用了该类的其他静态成员,可能引发 java.lang.ExceptionInInitializerError。
- 构造方法内避免调用可被子类重写的方法(可能访问到未初始化的字段)
- 静态内部类延迟加载时,
new外部类不会触发其初始化 - 使用
Class.forName("X")默认会初始化类;而ClassLoader.loadClass("X")不会
对象内存布局:从对象头到实例数据
JVM 对每个对象在堆中分配三块区域:对象头(mark word + 类型指针)、实例数据(字段值,含父类继承来的)、对齐填充(保证 8 字节对齐)。其中 mark word 在不同状态下存不同内容:无锁时存哈希码、GC 分代年龄、锁标志位;加锁后可能升级为轻量级锁记录或指向 Monitor 的指针。
字段排列顺序影响对象大小——JVM 会按宽度重排序(long/double → int → short/char → byte/boolean),但同宽字段仍按源码顺序。这意味着把 byte 和 long 相邻声明,比把多个 byte 放一起更浪费空间。
立即学习“Java免费学习笔记(深入)”;
- 用
java -XX:+PrintFieldLayout查看实际字段排布 - 对象头大小:64 位 JVM 开启指针压缩(默认开启)为 12 字节,否则 16 字节
- 空对象(如
new Object())在开启压缩指针下占 16 字节(12 字节头 + 4 字节对齐)
finalize() 已废弃,替代方案是 Cleaner 或 PhantomReference
finalize() 在 JDK 9 被标记为 @Deprecated,JDK 18 彻底移除。它不可靠:不保证何时执行、不保证一定执行、可能阻塞 GC 线程。现代替代方案是 Cleaner(基于 PhantomReference 实现),它把资源清理逻辑和对象生命周期解耦,由专门线程异步执行。
注意 Cleaner 不持有对象强引用,因此不会阻止 GC;但注册 cleaner 的动作本身需确保对象已完全构造完成(不能在构造器中直接注册,应在外层封装工厂方法)。
- 不要在
Cleaner动作中抛异常,会被静默吞掉 -
PhantomReference的get()永远返回null,只能通过ReferenceQueue检测对象是否被回收 - 像
FileChannel、DirectByteBuffer这些关键资源,JDK 内部已用Cleaner替代finalize
对象可达性判定:GC Roots 不只是栈变量
判断对象是否存活,JVM 从一组称为 GC Roots 的对象出发,进行可达性分析。Roots 不仅包括虚拟机栈(本地变量表)中的引用,还包括:方法区中类静态属性引用的对象、方法区中常量引用的对象(如字符串常量池里的 "abc")、本地方法栈中 JNI 引用的对象、以及 正在被同步锁持有的对象(即 synchronized(obj) 中的 obj)。
容易忽略的是:即使局部变量已超出作用域,只要栈帧还没出栈(比如还在 try-finally 里),它仍算 GC Root;另外,被 finalizer 队列引用的对象,在 finalize 执行前也不会被回收——这是唯一一次“复活”机会,但极不推荐依赖。
- 使用
jmap -histo:live查看当前存活对象统计 - 弱引用(
WeakReference)不作为 GC Root;软引用(SoftReference)在内存不足时才被回收 - 对象进入
F-Queue后,若 finalize 方法执行缓慢,会拖慢整个 GC 周期










