栈上分配本质是JIT通过逃逸分析后执行标量替换，将未逃逸对象拆解为独立标量存入局部变量表或寄存器，并非真正在栈中存放完整对象。
栈上分配不是把一个“完整对象”整个搬到栈上，而是通过逃逸分析确认该对象不会被方法外访问后，JIT 编译器选择不创建它——转而用更轻量的方式表达它的语义。关键在于：栈帧本身不支持直接存放 Java 对象的完整结构。
栈内存的物理限制决定了无法存“对象”
Java 虚拟机栈中每个栈帧只包含局部变量表、操作数栈等固定结构，其局部变量表只能存两类东西：基本类型（int、boolean 等）和对象引用（reference）。它没有预留空间来存储对象头、实例数据、对齐填充这些堆中对象必需的组成部分。所谓“在栈上分配对象”，本质是 JIT 放弃了对象的聚合形态，只保留程序真正用到的字段值。
标量替换才是栈上分配的实际执行方式
栈上分配在 HotSpot 中并不是独立实现的机制，而是标量替换（Scalar Replacement）的一种表现结果。只要满足两个条件：
- 对象未逃逸出当前方法（逃逸分析确认）
- 对象可被分解（即所有字段都是标量或可递归分解为标量）
JIT 就会跳过 new 指令，直接将字段拆成独立变量，例如：
Point p = new Point(1, 2); → 编译后变成两个 int 变量：x=1, y=2
这些变量自然落入局部变量表或寄存器中——这才是真正“在栈上”的内容。
完整对象结构依赖堆的运行时管理能力
一个 Java 对象在堆中存在，不只是因为“大”，更是因为它需要：
- 对象头（存储哈希码、GC 分代年龄、锁状态等元信息）
- 字段内存对齐（保证 CPU 高效读取）
- 统一的 GC 标记与回收路径
- 反射、序列化、同步块等运行时能力支撑
这些机制全部绑定在堆的对象模型上。栈帧没有 GC 元数据区、不参与写屏障、也不支持 monitor enter/exit 的对象级锁语义——所以 JVM 不可能、也不需要在栈上构造一个“有头有尾、能被 synchronized 锁住”的完整对象。
换句话说：栈上分配不是“搬对象”，而是“删对象”，再把有用的部分重建成标量。这不是限制，而是精准优化。
