new关键字创建对象时先触发类加载五阶段，待执行完毕才分配内存并调用；对象内存布局含对象头、实例数据、对齐填充；finalize已废弃，推荐cleaner；gc roots包括栈变量、静态属性、常量、jni引用及被锁对象。
new 关键字触发类加载与构造执行
Java 中绝大多数对象通过 new 创建，但这不是简单分配内存——它会隐式触发类加载（如果类未初始化）、验证、准备、解析、初始化五个阶段。只有当类的 <clinit></clinit> 方法执行完毕，new 才真正开始为对象分配堆内存，并调用 <init></init>（即你写的构造方法）。
常见误区是认为 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 -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 <pid></pid>查看当前存活对象统计 - 弱引用（
WeakReference）不作为 GC Root；软引用（SoftReference）在内存不足时才被回收 - 对象进入
F-Queue后，若 finalize 方法执行缓慢，会拖慢整个 GC 周期
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
