new触发类加载与实例化：先分配内存并设默认值，再调用构造器；类加载仅首次new时发生，static块在初始化阶段执行；另有四种非new创建方式；逃逸分析可使对象栈分配或消除。
new 关键字触发类加载与实例化
Java 中绝大多数对象通过 new 操作符创建，但这个动作背后会连锁触发多个阶段：类加载（如果尚未加载）、内存分配、初始化零值、执行 <init></init> 方法（即构造器）。注意，new 不等于“立刻完成初始化”——它分两步：JVM 先在堆上分配内存并设默认值（如 null、0、false），再调用构造器填充业务逻辑。
常见误区是认为 new Person() 一执行就“有了完整对象”。实际上若构造器中抛出异常（比如 NullPointerException），对象虽已分配内存，但初始化失败，不会返回引用，也不会触发 finalize（已弃用）或清理逻辑。
- 类加载由
ClassLoader触发，仅首次new同一类时发生 - 若类存在
static块，会在类加载阶段执行一次，早于任何new - 构造器内调用
this(...)或super(...)必须是第一行语句
构造器不是唯一创建对象的方式
除了 new，还有四种合法但易被忽略的途径，它们绕过构造器或不走常规流程：
-
Class.newInstance()（已废弃）：依赖无参构造器，且要求可访问；JDK 9+ 推荐用Constructor.newInstance() -
ObjectInputStream.readObject()：反序列化时直接恢复对象状态，不调用任何构造器（除非实现readResolve） -
Unsafe.allocateInstance()：跳过构造器和初始化，返回未初始化的对象（字段全为默认值），需反射获取Unsafe实例，仅限底层框架使用 - 克隆：
obj.clone()创建浅拷贝，不调用构造器，但要求类实现Cloneable接口
这些方式对 JVM 内存模型、监控工具（如 JFR）和调试器行为有差异。例如，Unsafe.allocateInstance() 创建的对象不会出现在 GC 日志的“allocation stack trace”中。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
对象内存布局与逃逸分析的影响
对象实际创建位置不总是在堆上。JVM（特别是 HotSpot）会通过逃逸分析判断对象是否“逃逸”出当前方法或线程作用域。若未逃逸，可能直接分配在栈上（标量替换），甚至被完全拆解为局部变量（消除对象本身）。
这意味着：即使你写了 new StringBuilder()，JIT 编译后可能根本不生成对象，而是把 char[] 和长度变量作为局部变量处理。这种优化不可见于源码，但影响性能和 GC 压力。
- 开启逃逸分析：JDK 8 默认启用（
-XX:+DoEscapeAnalysis） - 禁用后所有对象强制堆分配，可用于对比性能或排查“本该栈分配却没生效”的问题
-
String字面量、常量池对象不走 new 流程，属于类加载阶段的静态分配
类初始化时机容易被误判
很多人混淆“类加载”和“类初始化”。类加载（loading）只是把字节码读入方法区；而初始化（initialization）才执行 static 块和静态字段赋值。初始化只在以下**首次主动使用**时触发：
- 执行
new指令（对应该类） - 调用该类的静态方法或访问/赋值静态字段（
final常量除外） - 反射调用
Class.forName("X")（注意ClassLoader.loadClass()不触发初始化） - 子类初始化时，若父类未初始化则先触发父类初始化
典型陷阱：定义了 static final int PORT = 8080; 的类，被其他类引用该常量时，不会导致该类初始化——因为编译期已内联为字面量。
对象创建流程看似简单，但类加载时机、构造器执行边界、JIT 优化路径、以及非 new 创建方式的语义差异，都会在并发、序列化、监控或调优场景中暴露出来。真正关键的不是“怎么写 new”，而是理解每个环节谁在控制、何时发生、能否跳过。
