逃逸分析是jit编译时的动态数据流分析，仅对c2编译的热点方法中完全不逃逸的对象触发标量替换（非真正栈上分配），需满足无返回、无成员赋值、无逃逸参数传递等严格条件。
逃逸分析不是开关，而是 JIT 编译时的动态推断
逃逸分析本身不直接分配内存，它只是 C2 编译器在编译热点方法时做的数据流分析：跟踪每个 new 出来的对象引用是否可能被方法外读取。如果分析结论是“该对象绝不会被外部访问”，才触发后续优化——比如栈上分配或标量替换。这意味着：你写 new User() 并不能保证栈上分配；只有当 JIT 实际编译该方法、且逃逸分析确认无逃逸时，才可能生效。
常见错误现象包括：误以为加了 -XX:+DoEscapeAnalysis 就一定开启栈上分配（其实默认已开），或在非热点代码（未被 JIT 编译）中观察不到效果。
- JDK 8u60+ 默认启用逃逸分析，无需手动开启
-XX:+DoEscapeAnalysis - 必须是被 C2 编译的热点方法（通常需执行上千次），冷路径不会触发
- 对象必须是“完全不逃逸”：不能作为返回值、不能赋值给成员变量、不能传入可能逃逸的参数（如
System.out.println(obj)可能阻止优化）
栈上分配只在满足严格条件时发生，且 HotSpot 实际不直接做
很多人看到资料说“JVM 把对象分配在栈上”，但 HotSpot 虚拟机（主流 JDK 使用的 VM）从没实现过真正意义上的栈上分配（Stack Allocation）。它实际依赖的是 标量替换（Scalar Replacement）——这是更可行、更激进的替代方案。
所谓“栈上分配”，在 HotSpot 中表现为：JIT 拆掉对象结构，把它的字段（如 int id、String name）当作独立局部变量，直接分配在栈帧的局部变量表里，甚至进一步放入 CPU 寄存器。对象头、对齐填充、GC 标记等堆开销全部消失。
-
-XX:+EliminateAllocations控制标量替换（默认开启） -
-XX:+PrintEscapeAnalysis可打印逃逸分析结果，确认某对象是否被判定为allocates not escaped - 若字段含对象引用（如
String），且该引用本身也未逃逸，JIT 可能递归拆解（但深度有限） - 数组、final 字段、反射访问、JNI 调用都会中断标量替换
为什么你测不出栈上分配？因为 GC 日志和堆 dump 看不到它
标量替换后的对象，根本没在堆上创建，自然不会出现在 GC log 的分配统计里，也不会出现在 jmap -histo 或堆转储中。你只能通过间接证据验证：
- 开启
-XX:+PrintCompilation，确认方法被 C2 编译 - 加
-XX:+PrintEscapeAnalysis，查日志中是否有not escaped或arg escape等标记 - 对比开启/关闭
-XX:-EliminateAllocations后的分配速率（用jstat -gc观察YGC频率或EU增速） - 注意：微基准测试（如 JMH）容易因循环不变量优化掩盖效果，真实业务方法更易观察到收益
真正影响性能的是逃逸等级，不是“栈 or 堆”的二选一
对象是否逃逸，决定 JIT 能走多远的优化链：
无逃逸 → 标量替换（最激进）
方法逃逸（仅返回）→ 同步消除（synchronized 被干掉）
线程逃逸（如赋给 static 字段）→ 无优化，老老实实堆分配
所以关键不是“怎么让对象上栈”，而是“怎么写能让 JIT 相信它不会逃逸”。这比调参重要得多。
- 避免将局部对象返回、避免存入集合、避免传给泛型方法（类型擦除可能导致逃逸判断保守）
- 慎用
var或复杂链式调用（如builder.build().get().toString()），JIT 可能无法穿透多层引用 - 字段尽量用基本类型；含
String的类，若String本身来自常量池或不可变构造，更易被拆解
标量替换不是银弹。它只对高频创建、短生命周期、结构简单的对象有效；一旦对象变大、含锁、或引用外部状态，JIT 会自动降级回堆分配。别试图强行“塞”对象上栈——让代码自然符合无逃逸特征，才是稳定获得优化的前提。
