构造方法引用（如MyClass::new）不分配内存也不初始化，仅是函数式接口载体；真正创建对象分三步：堆内存分配（含零值初始化）、设置对象头、执行方法，三步非原子且可被中断。
构造方法引用（如 MyClass::new）本身不分配内存，也不执行初始化；它只是函数式接口的实现载体，真正的内存分配与对象初始化发生在调用时（比如通过 Supplier.get()），而这个过程在 JVM 层面**不是原子操作**——它由多个可观察、可中断的步骤组成。
内存分配与初始化是两阶段过程
JVM 创建对象实际分为清晰的三步：
- 分配内存：在堆中划出一块足够大小的空间（可能涉及指针碰撞或空闲列表，取决于 GC 算法）；此时对象仅是一块未初始化的内存块，字段值为默认零值（0、null、false）；
- 设置对象头：写入类元数据指针、哈希码、GC 分代年龄、锁状态等信息；
-
执行
<init></init>方法：即构造方法体，按源码顺序对字段赋值、调用父类构造器、执行初始化块等。
这三步之间没有原子性保障。例如，在多线程环境下，若一个线程刚完成内存分配和对象头设置（但尚未执行构造逻辑），另一个线程就通过某种方式（如逃逸分析失效+反射/Unsafe）访问该对象，就可能读到字段的默认值而非预期初值——这就是“半初始化对象”问题。
构造方法引用不改变底层行为
MyClass::new 被编译为 invokedynamic 指令，最终绑定到一个生成的静态工厂方法（如 lambda$xxx$0）。该方法内部仍是标准的 new MyClass + dup + invokespecial <init></init> 字节码序列。它不引入额外同步，也不合并分配与初始化为单条指令。JVM 规范从未承诺对象创建是原子的，HotSpot 实现也明确将其拆解为可安全点检查的多步操作。
哪些场景会暴露非原子性
以下情况可能观测到构造未完成的对象状态：
- 对象在构造中发布（this 逃逸），被其他线程提前持有并访问字段；
- 使用
Unsafe.allocateInstance()绕过构造方法，只分配内存不调用<init></init>； - 在
<init></init>执行中途发生线程切换，且该对象被全局缓存或监听器注册； - JIT 编译器因重排序优化，使字段写入在构造完成前对其他线程可见（final 字段除外，有特殊语义保证）。
如何获得强初始化保证
若需确保“分配 + 初始化”对外不可见直到完全结束，可借助语言级机制：
- final 字段：JMM 保证在构造方法内对 final 字段的写入，对后续任意线程读取该对象时都可见（happens-before 保证）；
- 安全发布：将新对象放入 volatile 字段、ConcurrentMap 或通过 synchronized 块发布；
- 静态工厂 + 私有构造：配合枚举、单例或 Builder 模式，控制对象可见时机；
- 避免 this 逃逸：不在构造方法中启动线程、注册监听、将 this 传入外部方法。
构造方法引用只是语法糖，它不增强、也不削弱底层对象生命周期的语义边界。理解其背后仍是标准 new + init 的字节码链条，就能看清所谓“原子性”并不存在——关键在于你如何控制对象的发布时机和可见范围。
