类加载阶段包括加载、链接（验证、准备、解析）、初始化三步；准备阶段赋静态变量默认值，初始化阶段执行static块和显式赋值，且同一类加载器下仅初始化一次。
类加载阶段到底发生了什么
类的实例化不是从 new 开始的，而是从类加载开始。JVM 首次遇到某个类（比如通过 new MyClass()、静态字段访问、反射等）时，会触发该类的加载、链接（验证、准备、解析）、初始化三步。其中「准备」阶段给静态变量赋默认值（如 int 为 0），「初始化」阶段才执行 static 块和静态变量显式赋值。
注意：同一个类加载器下，一个类只会被初始化一次。多次 new 不会重复触发类初始化，但会重复执行构造方法。
内存分配与对象头布局的关键细节
执行 new 时，JVM 在堆中为对象分配内存（大小在类加载后就已确定）。分配方式取决于垃圾收集器：指针碰撞（Serial/ParNew）或空闲列表（CMS/G1）。如果开启 -XX:+UseTLAB（默认开启），线程优先在本地线程分配缓冲区（TLAB）中分配，避免同步开销。
分配完内存后，JVM 立即清零（保证实例变量有默认值），然后设置对象头——包括哈希码（延迟计算）、GC 分代年龄、锁状态、指向类元数据的指针（Klass Pointer）。这些信息不靠 Java 代码控制，但影响 hashCode()、synchronized 和 GC 行为。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 对象头大小因 JVM 位数和是否开启压缩指针而异：64 位 + 关闭压缩指针 → 类指针占 8 字节；开启（
-XX:+UseCompressedClassPointers）→ 占 4 字节 -
java.lang.Class实例本身也存在堆中，它就是该类的「运行时类型信息」载体，obj.getClass()返回的就是它
构造方法执行前的隐式动作链
你写的构造方法并不是第一个被执行的逻辑。JVM 会自动插入隐式动作：
- 若未写
super()或this(...)，编译器自动插入super()（调用父类无参构造） - 父类构造方法执行前，先确保其父类已初始化（递归向上）
- 实例变量的显式初始化（如
private int x = 5;）被编译器“搬进”构造方法，在super()调用之后、你写的代码之前执行 - 因此，不要在构造方法中调用可被子类重写的方法（如
this.init()），此时子类字段可能还未初始化
示例：class B extends A { int v = 10; B() { super(); v = 20; } } 中，v = 10 的赋值发生在 super() 返回后、v = 20 之前。
对象创建失败时的异常捕获边界
OutOfMemoryError: Java heap space 可能在三个环节抛出：类加载时（元空间不足）、内存分配时（堆满且无法扩展）、构造方法内（比如内部新建大数组）。但要注意：
-
try-catch只能捕获构造方法执行过程中抛出的异常（如IllegalArgumentException），捕获不到 OOM —— 因为 OOM 是 JVM 层面的致命错误，通常无法安全恢复 - 如果构造方法中启动线程、注册监听器或持有外部资源，而构造中途抛异常，这些操作不会自动回滚，必须手动处理（如在
catch中清理） - 使用
Unsafe.allocateInstance()可绕过构造方法创建对象（字段全为默认值），但非常规手段，且破坏封装和安全性
真正容易被忽略的是：对象引用是否成功写入变量，取决于构造方法是否完成。如果构造中抛异常，栈上引用保持为 null，不会留下半初始化对象——这是 JVM 保证的语义安全底线。
