jvm逃逸分析不直接优化分配，而是通过静态分析引用路径判断对象是否逃逸；仅当对象不逃逸（不返回、不赋值给静态/实例字段、不传入外部方法或线程）时，jit才触发标量替换，将字段拆为局部变量存栈或寄存器，消除堆分配与gc开销。
JVM 逃逸分析本身不直接“优化分配”，而是为后续优化提供决策依据。它通过静态分析对象的引用传播路径，判断其是否可能被方法外访问；一旦确认不逃逸，JIT 编译器就能跳过堆分配，改用更轻量的方式处理对象——这才是性能提升的关键。
逃逸分析怎么决定对象能不能“不进堆”
它不运行代码，只扫描字节码中的引用流向，重点看三类行为：
- 对象是否作为返回值传出当前方法
- 是否被赋给 static 字段、this 字段，或传入非 private 方法（哪怕只是 list.add(obj)）
- 是否被发布到其他线程（如放进 ThreadLocal、线程池任务、并发容器）
全部否决，才标记为 does not escape —— 这是触发后续优化的唯一入口。
真正起作用的是标量替换，不是栈上分配
HotSpot JVM（JDK 8–21）从未实现真正的栈上分配。所谓“栈分配”，实际是标量替换（Scalar Replacement）：JVM 拆解对象，把它的字段（如 int x, int y）变成独立的局部变量，存入栈帧的局部变量表或 CPU 寄存器中。
- 对象根本不会被构造，new 指令在汇编层消失
- 字段操作变成对 %rax、%rdx 等寄存器的直接读写
- 没有对象头、没有 GC 跟踪开销、没有内存布局成本
哪些写法会让逃逸分析立刻失效
即使逻辑上对象没逃逸，某些语言特性或调用模式也会让 JIT 放弃分析：
- 调用 toString()、hashCode()、wait() 等可被子类重写的方法（虚调用无法判定行为）
- 使用反射（Field.set、Method.invoke）
- 对象字段含引用类型（如 String、List），整个替换就中止
- 方法被 JVMTI agent 修改过字节码，或类由 CGLIB 动态生成
怎么验证优化是否生效
别看堆内存或 GC 日志——标量替换的对象压根不进堆。可靠方式只有两个：
- 加参数 -XX:+PrintEscapeAnalysis -XX:+UnlockDiagnosticVMOptions，启动后观察日志是否出现 does not escape
- 配合 -XX:+PrintOptoAssembly（需提前装 hsdis），检查 JIT 编译后的汇编：若原 new Point() 变成寄存器赋值序列，说明已拆解
再关掉逃逸分析（-XX:-DoEscapeAnalysis）对比耗时，若循环创建对象明显变慢，基本可确认优化在起作用。
