jvm对象内存分配的线程安全通过cas原子操作与tlab两种机制保障：指针碰撞时用cas+重试更新分配指针；空闲列表时采用细粒度锁或cas更新链表；tlab为各线程提供私有缓冲区，大幅减少同步开销。
JVM 在对象内存分配过程中，必须确保多线程环境下堆内存操作的线程安全。由于多个线程可能同时执行 new 指令，若不加控制，会出现指针错位、内存覆盖或重复分配等问题。其核心同步机制不是靠传统锁粗粒度保护整个堆，而是采用两种轻量、高效且互补的策略。
指针碰撞下的 CAS + 失败重试
当堆内存规整（如使用 Serial、Parallel GC）时，JVM 采用“指针碰撞”方式分配：维护一个指向空闲内存起始位置的指针（如 top）。分配对象即原子性地将该指针向后移动对象大小的距离。
为避免竞态，JVM 使用 Unsafe.compareAndSwapInt/Long 原子指令更新指针：
- 线程读取当前
top值作为分配起点 - 计算新指针值：
top + objectSize - 尝试用 CAS 将
top从旧值更新为新值 - 若失败（其他线程已抢先更新），则重读
top并重试
该方式无锁、低开销，适用于高并发短对象分配场景。
TLAB（线程本地分配缓冲区）
JVM 为每个线程在 Eden 区中预先划分一小块私有内存区域，即 TLAB。对象优先在本线程的 TLAB 中分配，完全避免了跨线程竞争。
关键细节包括：
- TLAB 大小由 JVM 自动估算（默认开启，可通过
-XX:+UseTLAB控制） - 当 TLAB 空间不足时，触发一次小规模同步：尝试在 Eden 区分配新 TLAB，此时才需 CAS 或轻量锁
- 超大对象（超过 TLAB 剩余空间或阈值）直接在 Eden 公共区分配，走 CAS 路径
TLAB 是空间换时间的典型设计，大幅减少同步频率，是现代 JVM 的标配优化。
空闲列表下的同步控制
当堆内存不规整（如使用 CMS、G1 的部分阶段），JVM 维护“空闲列表”记录可用内存块。此时分配需从链表中查找合适区块并移除节点，操作本身不具备原子性。
为保证线程安全，JVM 通常采用：
- 对空闲列表结构加细粒度锁（如分段锁），而非全局锁
- 或结合 CAS 更新链表头节点，配合自旋重试
- 某些 GC 实现（如 G1）会将空闲内存按 Region 划分，降低锁争用范围
相比指针碰撞，空闲列表分配开销略高，但更适应碎片化内存场景。
同步机制与锁无关，也不依赖 synchronized
需要明确的是：对象分配阶段的同步，不涉及任何 Java 层面的 monitor 锁（即 synchronized）。它发生在虚拟机底层，基于硬件 CAS 指令和内存屏障实现，与对象头中的 Mark Word 状态无关。
也就是说：
-
synchronized保护的是对象创建后的访问逻辑，不是创建过程本身 - 分配时的同步是 JVM 内存管理器的基础设施行为，对 Java 程序员透明
- 即使关闭所有用户级锁，JVM 仍能安全完成多线程对象分配
理解这一点，有助于区分“内存分配同步”与“对象使用同步”的不同层级和职责。
