逃逸分析在Java 8u60+默认开启，但仅当满足未禁用分层编译、方法被C2编译且未启用EliminateAllocations时才生效；验证需通过PrintEscapeAnalysis查看JIT日志中的scalar replaceable输出。
逃逸分析到底开了没？先看JVM是否真启用
Java 8u60+ 默认开启 -XX:+DoEscapeAnalysis，但实际是否生效，得看是否同时满足三个条件：未启用 -XX:+EliminateAllocations（它依赖逃逸分析）、未禁用分层编译（-XX:-TieredStopAtLevel=1 会关掉C2编译器，而逃逸分析只在C2中做）、且方法必须被JIT编译到C2层级（即热点代码）。光加参数不等于起作用。
验证方式很简单：java -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis YourApp。如果看到类似 45 1 java.lang.String::length (5 bytes) made not entrant 后紧跟着 Escape Analysis: scalar replaceable 或 not scalar replaceable，说明逃逸分析已介入。
- 常见错误现象：加了参数但
PrintEscapeAnalysis没输出——大概率是代码没触发JIT，或用了-Xint强制解释执行 - 使用场景：只对被C2编译的、非构造器/同步块内、对象生命周期局限在栈帧内的局部对象起作用
- 注意
-XX:+DoEscapeAnalysis在Java 15+ 已被标记为废弃，但目前仍有效；Java 17+ 中默认仍开启，无需显式配置
怎么写代码才能让对象“不逃逸”？关键在作用域和引用传递
逃逸分析不是靠猜，而是看对象的引用有没有“跑出当前方法”。哪怕只有一行 return obj、list.add(obj)、staticField = obj，对象就逃逸了，JVM立刻放弃标量替换。
典型可优化代码长这样：
立即学习“Java免费学习笔记（深入）”；
public static void test() {
Point p = new Point(1, 2); // Point 是普通类，无final字段限制也行
int x = p.x + p.y;
// p 没被传给任何外部方法，没赋值给静态/成员变量，没作为返回值
}
- 容易踩的坑：以为把
new写在方法里就一定不逃逸——错。只要引用被“传出”，比如传入System.out.println(p)，而println内部可能保存引用（实际不会，但JVM保守处理），就可能判定逃逸 - 参数差异：
@Contended或final字段不影响逃逸判定；但对象若含 native 方法调用（如Object.clone()），JVM会直接放弃分析 - 性能影响：标量替换后，对象字段直接分配在栈上或寄存器里，避免堆分配和GC压力；但若误判逃逸，反而多一次分析开销（极小）
为什么加了参数也没看到性能提升？逃逸分析不是万能加速器
逃逸分析本身不提速，它只是为标量替换、锁消除等优化提供前提。真正见效，得看后续优化是否落地，以及你的瓶颈是否在堆分配。
- 常见错误现象：对比加/不加
-XX:+DoEscapeAnalysis，吞吐量几乎没变化——很可能你压根没触发标量替换，或者对象本就很小，分配成本低到无法测出差异 - 使用场景：适合高频创建短命小对象的场景（如数学计算中的
Vector3d、BigDecimal中间结果），对大对象或长生命周期对象无效 - 兼容性影响：不同JDK版本C2优化策略不同；Java 11~17 对逃逸分析更激进，但某些corner case（如Lambda捕获）仍可能抑制标量替换
- 别忘了关掉GC日志干扰：
-Xlog:gc*=debug会显著拖慢运行，掩盖真实效果
想确认标量替换发生了？看JIT日志比看GC更直接
最可靠的证据不是内存减少，而是JIT编译日志里出现 scalar replaced 或 allocated 变成 scalar replaced。配合 -XX:+PrintAssembly（需hsdis）能看到字段直接映射到寄存器，但门槛高；日常调试用日志足够。
- 实操建议：用
-XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis -XX:+PrintCompilation启动，专注观察目标方法编译后的那几行escape相关输出 - 容易忽略的点：同一个类的方法，有的被C2编译，有的还在C1，逃逸分析只发生在C2阶段；所以要确保测试循环足够热（比如1万次以上），否则看不到日志
- 注意
PrintEscapeAnalysis输出非常密集，建议重定向到文件并 grep 关键字，比如grep "Point::<init\|scalar"
逃逸分析的实际效果高度依赖代码结构、JIT编译时机和JDK版本，同一段代码在不同环境表现可能完全不同——别只盯着参数，先确认它真的跑起来了，再看它替换了什么。
