HotSpot JVM 并未实现真正的栈上分配，所谓“栈上分配”实为逃逸分析触发的标量替换与同步省略；对象不逃逸时，JIT 将其拆分为标量存入局部变量表或寄存器，跳过堆分配；因栈帧大小固定、GC Roots 枚举限制及语义安全风险，HotSpot 源码中仍标记为待实现。
HotSpot JVM 并不实际实现栈上分配（Stack Allocation），所谓“栈上分配”在当前 JDK 8–21 中仍是未启用的优化项。你看到的性能提升，本质来自逃逸分析驱动的标量替换与同步省略，而非对象真的被压入虚拟机栈。
逃逸分析只做判定，不负责分配
逃逸分析是 JIT 编译阶段的静态数据流分析技术，它不分配内存，只回答一个问题：这个对象会不会“跑出”当前方法的作用域？判断依据是引用是否被：
- 作为返回值传出
- 赋值给类字段、static 变量或外部容器（如全局 List）
- 作为参数传入其他方法（含 lambda 捕获）
- 被 volatile 写、Unsafe 操作或 synchronized 块以外的方式跨线程暴露
真正生效的不是“栈分配”，而是标量替换
当对象被判定为“不逃逸”，且结构简单（字段全为基本类型或不可变引用、无虚方法调用、无同步块），JIT 会启用标量替换（-XX:+EliminateAllocations，默认开启）：
- 把对象拆成独立字段，如 Point p = new Point(1, 2) → 直接生成 int px = 1; int py = 2;
- 字段直接存入局部变量表，甚至进一步进寄存器（%rax、%rdx 等）
- 完全跳过对象头、内存布局、堆分配指针碰撞等开销
验证它是否起效，得看编译日志和汇编
别靠猜测，用参数实锤：
- 加 -XX:+PrintEscapeAnalysis -XX:+UnlockDiagnosticVMOptions，看到 does not escape 才说明逃逸分析已识别成功
- 关掉对比：-XX:-DoEscapeAnalysis，若循环中新建对象耗时明显上升（如 120ms → 350ms），说明分析确实在起作用
- 配合 -XX:+PrintOptoAssembly（需 hsdis），观察字段是否变成寄存器操作——那是标量替换落地的铁证
为什么 HotSpot 不做真正的栈上分配？
不是不想，是不能轻易做：
- 栈帧大小固定（默认 1MB），大对象栈分配易触发 StackOverflowError
- 对象若含 final 字段、有 monitor、或涉及反射/JNI，分析保守性升高，极易误判逃逸
- 栈上对象无法被 GC Roots 枚举，一旦发生异常导致栈帧未正常退出，可能引发内存语义错误
- HotSpot 源码中仍标记为 // TODO: implement stack allocation
