HotSpot JVM 并未实现栈上分配，所谓“逃逸分析生效”实为标量替换：对象被拆解为字段级变量存入寄存器或栈槽，而非真分配到栈上；验证需用-XX:+PrintEscapeAnalysis观察does not escape，并用-XX:+PrintOptoAssembly确认汇编中无new指令、仅有寄存器操作。
HotSpot JVM 并不真正做栈上分配，所谓“逃逸分析生效”绝大多数时候是标量替换（Scalar Replacement）在起作用，不是对象被分配到了栈上，而是对象根本没被创建。
怎么确认逃逸分析是否真的触发了优化
别看 GC 日志或堆 dump —— 那些只反映堆上发生了什么，而标量替换会让对象彻底消失，连堆都不进。真正有效的验证方式只有两条：
- 用
-XX:+PrintEscapeAnalysis -XX:+UnlockDiagnosticVMOptions启动，观察日志里是否出现does not escape（说明逃逸分析判定未逃逸），但绝不会看到allocates to stack（因为 HotSpot 当前所有版本都未实现栈上分配） - 配合
-XX:+PrintOptoAssembly（需提前装好 hsdis），看 JIT 编译后的汇编：如果原本的new Rect()变成了对%rax、%rdx等寄存器的独立赋值和运算，就说明字段被拆开、标量替换了
为什么关闭 -XX:-DoEscapeAnalysis 后性能反而下降
这不是因为“栈分配变快了”，而是因为逃逸分析为后续优化提供了前提。关掉它，JIT 就不敢做这些事：
- 标量替换失效 → 大量临时对象照常在堆上分配 → GC 压力上升
- 锁消除失效 → 即使是
synchronized(new Object())这种明显无竞争的代码，也会真实执行加锁/解锁流程 - 方法内联可能受阻 → 对象作为参数传入时，若无法证明其不逃逸，JIT 会更保守地拒绝内联调用
典型表现是循环体中每轮新建对象的耗时从 120ms 涨到 350ms，差距来自对象分配 + GC + 同步开销三重叠加。
哪些写法会让逃逸分析“直接放弃”
逃逸分析是静态字节码分析，它不运行代码，只看控制流和引用传递路径。以下情况会让对象立刻被判为 ArgEscape 或 GlobalEscape：
- 把局部对象赋值给
this.field或static field - 作为参数传给任意一个非
private方法（哪怕那个方法实际没逃逸，JIT 也不敢跨 class 做强假设） - 调用
toString()、hashCode()、wait()等可能被子类重写的方法（JIT 无法确定最终行为） - 用反射访问字段（
Field.set()）或调用方法（Method.invoke()）
哪怕只是 list.add(obj)，只要 list 是方法参数传入的，对象就算逃逸 —— 因为 JIT 无法确定这个 list 是否被其他线程持有。
别信“栈上分配”宣传，盯紧标量替换的实际效果
所有声称“JVM 把对象分配到了栈上”的文章或文档，要么过时，要么混淆概念。HotSpot 自 JDK 6 到 JDK 21 的源码里，stack allocation 相关逻辑始终被注释为 // Not implemented 或 // TODO: implement stack allocation。
真正起效的是标量替换：它把 Rect r = new Rect(1, 2) 拆成两个局部变量 r_x = 1、r_y = 2，再进一步压进寄存器。这意味着：
- 没有对象头开销（12 字节）
- 没有引用存储成本（8 字节指针）
- 没有 GC 跟踪负担（字段变成纯标量，JIT 完全按基本类型处理）
所以优化的关键不在“分配位置”，而在“是否需要以对象形态存在”。想让逃逸分析生效，核心不是减少 new，而是切断所有向外暴露的引用链 —— 这比调参数重要得多。
