逃逸分析默认开启但未必生效，需方法内联完成且对象未逃逸（不被返回、不存堆/静态字段、不同步外暴露）；栈上分配实为标量替换，将字段拆为局部变量；同步消除仅适用于未逃逸的内置锁。
逃逸分析到底有没有生效？别只看JVM参数
加了 -XX:+DoEscapeAnalysis 不代表逃逸分析就真在干活。HotSpot 默认开启逃逸分析（JDK 8u60+），但实际是否触发，取决于方法内联是否完成、代码结构是否满足分析前提。常见错误是写了个看似“局部”的对象，却因为被传入 System.out.println() 或日志框架而逃逸——这些调用会阻止编译器判定为“不逃逸”。
- 逃逸分析发生在 JIT 编译阶段（C2），解释执行或 C1 编译下基本不生效
- 对象必须在方法内创建、未被返回、未被存入静态/堆字段、未被同步块外暴露引用
- 用
-XX:+PrintEscapeAnalysis可输出分析日志，但需配合-XX:+UnlockDiagnosticVMOptions - 简单 getter/setter、lambda 表达式捕获、Stream 中的临时对象都容易意外逃逸
栈上分配不是把对象真放栈里
“栈上分配”是逃逸分析后的优化结果之一，但 JVM 并不会真的把对象布局在 Java 栈帧里——而是把对象的字段拆开，作为局部变量直接分配在栈帧中（类似 C 的 struct 展开）。所以你不会看到 new Object() 在栈上构造，只会看到它的字段变成独立的 int、Object 类型局部变量。
- 仅适用于未逃逸的、非数组的对象（数组不支持栈上分配）
- 对象大小受限制：默认超过 64 字节（由
-XX:MaxStackAllocationSize控制）会退回到堆分配 - 无法通过反射或
Unsafe获取该对象地址——它根本不存在“对象头”和完整内存布局 - GC 压力降低是因为没有堆内存申请/回收动作，但栈空间消耗略增（通常可忽略）
标量替换和同步消除依赖同一份逃逸结论
标量替换（Scalar Replacement）和同步消除（Lock Elision）不是独立开关，它们都基于逃逸分析输出的“该对象未逃逸”这一判断。一旦判定不逃逸，C2 编译器才可能进一步拆解字段（标量替换），或直接删掉 synchronized 块（同步消除）。
- 标量替换后，原对象彻底消失，字段变成独立局部变量；若字段本身是对象（如
String），且该字段也不逃逸，可能继续递归替换 - 同步消除只对无竞争、且锁对象未逃逸的
synchronized生效；若锁对象被传给其他方法，哪怕没实际竞争，也会保留同步指令 -
synchronized(this)很难被消除，因为this几乎总逃逸（比如被返回、被存入集合） - 使用
ReentrantLock不会被同步消除——JIT 只识别内置锁
怎么验证这些优化真的发生了？
别信参数，要看编译日志和字节码行为。最直接的方式是观察 GC 日志中对应代码段的分配速率是否下降，再结合 -XX:+PrintCompilation 确认方法是否被 C2 编译，最后用 -XX:+PrintEscapeAnalysis 查看分析结果。
立即学习“Java免费学习笔记（深入）”；
- 启用
-Xlog:gc+allocation=debug（JDK 10+）可打印每次分配的调用栈，确认热点对象是否还在堆上出现 - 用 JMH 写对比测试时，注意预热要充分（至少 10 轮），否则逃逸分析可能还没触发
- 对象被
final字段持有、或构造函数里有this泄露（如注册监听器），都会导致逃逸分析失败 - 不同 JDK 版本差异大：JDK 15 后部分场景下逃逸分析能力反而弱化，因转向更激进的 inline 和 G1 的 RSet 优化
真正难的不是理解概念，是写出能让 JVM 看懂“这东西真的不用上堆”的代码——它比写业务逻辑还讲究控制流和引用边界。
