new触发类加载、链接与初始化（执行），再分配内存、设默认值、执行（隐式super()→父类构造→字段初始化→子类构造）；另有反射、反序列化等绕过构造器的创建方式。
new 关键字触发的类加载与初始化顺序
Java 中 new 一个对象时，并非直接分配内存就完事。JVM 会先确保该类已被加载、链接（验证、准备、解析）、初始化——尤其是「初始化」阶段，会执行 <clinit></clinit> 方法（静态代码块 + 静态字段赋值），且只执行一次。
- 如果类从未被使用过，
new会触发整个类加载流程；若已加载但未初始化（比如仅访问了某个静态常量），则此时才执行<clinit></clinit> - 父类的
<clinit></clinit>总是优先于子类执行，哪怕子类的new表达式写在最前面 - 注意：
final static基本类型常量（如public static final int MAX = 100;）在编译期就内联，不会触发类初始化
对象内存分配与构造器调用的真实步骤
类初始化完成后，JVM 才真正开始实例化：分配内存 → 设置默认值 → 执行 <init></init>（即构造器）→ 返回引用。这里容易误以为「构造器第一行没写 super() 就不调父类构造器」，其实不是。
- 每个构造器第一行隐式或显式调用另一个构造器（
this(...)）或父类构造器（super(...)）；若都没写，编译器自动插入super() - 父类构造器执行完，才轮到子类构造器中
super()后的代码；字段初始化（非静态代码块和字段声明处的赋值）发生在super()返回之后、构造器其余代码之前 - 内存分配可能走「指针碰撞」（堆规整）或「空闲列表」（堆碎片），取决于 GC 算法；TLAB（Thread Local Allocation Buffer）可避免并发加锁，但不是所有对象都进 TLAB
哪些方式不算「new」却也能创建对象
除了最常见的 new，Java 还有多种绕过构造器或不触发类初始化的对象创建路径，它们行为差异很大，容易引发问题。
-
Class.newInstance()：已废弃，要求无参构造器且必须是 public；会触发类初始化 -
Constructor.newInstance()：推荐替代，支持私有/带参构造器；同样触发类初始化 - 反序列化（
ObjectInputStream.readObject()）：不调任何构造器，直接分配内存并填充字段；不触发类初始化（但会触发反序列化类本身的加载） -
Unsafe.allocateInstance()：完全跳过构造逻辑，字段全为默认值（null/0/false）；需反射获取Unsafe实例，且 JDK 9+ 默认限制
常见陷阱：字段初始化顺序与多线程可见性
看似简单的字段赋值，在构造器中可能因重排序或未同步导致其他线程看到“半初始化”对象——尤其在单例双重检查锁定（DCL）中。
立即学习“Java免费学习笔记（深入）”；
- 即使构造器内部把
instance = this写在最后，JVM 或 CPU 仍可能将对象引用写入操作提前（只要不改变单线程语义） - 解决办法：对引用字段加
volatile（禁止指令重排 + 提供可见性保证），或用final字段（JMM 保证构造器结束前对 final 字段的写入对其他线程可见） - 不要在构造器中泄露
this（如启动线程、注册监听器、传给静态容器），此时子类字段可能还未初始化，或对象尚未对其他线程安全发布
public class UnsafeInit {
private static volatile UnsafeInit instance;
private final int value;
private UnsafeInit() {
// 危险：this 引用逃逸
new Thread(() -> System.out.println(this.value)).start();
this.value = 42; // 其他线程可能看到 0
}
public static UnsafeInit getInstance() {
if (instance == null) {
synchronized (UnsafeInit.class) {
if (instance == null) {
instance = new UnsafeInit(); // 构造器中 this 已泄露
}
}
}
return instance;
}
}
对象创建远不止 new 两个字符的事；类加载时机、字段初始化顺序、构造器链、内存模型约束，每一步都可能成为 bug 的温床。尤其当涉及反射、序列化或并发时，必须明确当前路径是否执行构造逻辑、是否触发类初始化、字段是否已安全写入。 
