逃逸分析由JIT在方法成为热点后动态触发，HotSpot仅支持标量替换而非栈上分配；验证需用-XX:+PrintEscapeAnalysis看逃逸判定，标量替换生效需对象完全不逃逸、类未被增强、字段类型干净且方法被内联。
逃逸分析到底有没有在运行？别猜，看日志
逃逸分析不是开关一开就“生效”的魔法，它由 JIT 编译器在方法被多次调用（成为热点）后动态触发，且结果高度依赖上下文。你写的 new Point(1, 2) 在 A 方法里可能被标量替换，在 B 方法里调用一次 return p 就立刻全局逃逸——优化直接失效。
验证唯一可靠方式是加 JVM 参数看实际分析结论：
-
-XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis：输出每个方法中对象的逃逸判定，如Point not escaped或Point is global escape -
-XX:+PrintOptoAssembly（需 hsdis 支持）：进一步确认是否真的做了标量替换（汇编里看不到 new 指令，只有 mov、add 等寄存器操作） - 注意：JDK 8u60+ 默认开启逃逸分析，但某些场景（如启用
-XX:-TieredStopAtLevel=1禁用 C2 编译器）会自动关闭
栈上分配为什么总没看到效果？
HotSpot JVM 目前（截至 2026 年）**并未真正实现栈上分配（Stack Allocation）**。这是最容易被资料误导的一点：大量文章把“逃逸分析通过 → 栈上分配”当成既定事实，但 HotSpot 的源码和官方文档明确说明，它只支持标量替换作为逃逸分析的落地手段，而“栈上分配”在 HotSpot 中仍为未实现特性（仅保留逻辑占位）。
所以你不会在 GC 日志或堆内存监控里看到“栈对象减少”，也不会因开启逃逸分析而显著降低 Young GC 次数——除非标量替换成功，把对象彻底拆没了。
- 常见误判原因：把标量替换的效果（无对象创建）当成栈上分配（对象在栈帧里）
- 真正影响 GC 的，是标量替换后连堆分配都跳过了，而不是对象从堆挪到了栈
- 如果你在 JVM 日志里看到
stack allocation failed: too large，那基本可以确定你正在用非 HotSpot 虚拟机（如 Excelsior JET），或者日志被错误引用
标量替换生效的硬性条件有哪些？
标量替换是逃逸分析最实用、也是目前 HotSpot 唯一稳定落地的优化。但它很“挑人”，不满足任一条件就会退回到普通堆分配。
- 对象必须 完全不逃逸：不能赋值给任何字段（
this.p = new Point()）、不能放入数组/集合、不能作为参数传给其他方法（哪怕只是log(p)）、不能被反射或toString()访问 - 类不能被动态增强：Spring AOP/CGLIB、Hibernate 字节码织入生成的代理类，JIT 无法做字段级推断，直接放弃替换
- 字段类型要“干净”：若
Point里有个String name，而该String本身又逃逸了，整个Point就无法被完全替换；但如果name是常量字符串（来自字符串池），且未被外部引用，仍有可能部分替换 - 方法必须被内联：如果
calculateDistance()调用了getP1()，而getP1()没被内联，JIT 就无法确认返回的Point是否逃逸
同步消除（锁消除）怎么突然变快了？
你写 new StringBuffer().append("a").append("b")，明明用了 synchronized 方法，性能却和 StringBuilder 差不多？这就是逃逸分析触发的同步消除。
JIT 发现这个 StringBuffer 实例：
- 只在当前方法内创建
- 所有方法调用都在单线程栈内完成
- 没有引用被传出（没 return、没 setField、没进容器）
→ 确认它不可能被其他线程竞争 → 直接把所有 synchronized 字节码抹掉，连 MonitorEntry 都不进。
但注意：一旦你把它塞进 ThreadLocal、静态 Map，或传给一个未内联的工具方法，锁就回来了——不是 JIT 失效，而是逃逸判定变了。
这解释了为什么有些“临时拼字符串”场景下 StringBuffer 和 StringBuilder 性能几乎无差别，而另一些看似相似的代码却慢一截：差的不是类，是逃逸路径。
真正难的是让 JIT “看全”整个调用链，而不仅仅是你的那一行 new。它不像人眼能跳读逻辑，它得把每条字节码路径都静态推演清楚——这点，连很多资深开发者都会下意识忽略。
