逃逸分析默认开启但效果取决于代码结构和运行时行为；判断对象是否逃逸关键看其引用是否“传出”，需结合-xx:+printescapeanalysis和-xx:+printeliminateallocations观察c2编译后的实际优化结果。
逃逸分析不是开关式功能，它默认开启但效果高度依赖代码结构和运行时行为；直接观察“是否消除”比猜测更可靠。
怎么看一个对象到底有没有逃逸
不能只看源码里对象是不是在方法内 new 出来——关键看它是否被“传出”。JVM 会跟踪字节码中 putfield、getstatic、monitorenter、方法返回指令等路径。常见逃逸点包括：
- 作为方法返回值（如
return new Rect()） - 赋值给静态字段或实例字段（如
this.cache = new Rect()） - 传入其他方法且该方法可能存储引用（如
other.process(rect)，而process内部做了缓存） - 被同步块锁定（
synchronized(obj)），且 JVM 无法证明该锁不会被其他线程看到
注意：即使没显式 return 或赋值，反射、JNI、Lambda 捕获、Stream 中的中间操作都可能隐式导致逃逸，需结合实际调用链判断。
用 -XX:+PrintEscapeAnalysis 观察分析过程
这个参数会输出 C2 编译器对每个方法的逃逸判定结果，是验证优化是否生效的第一手依据：
- 启动时加上
-XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis - 关注日志中类似
escaped method: java/lang/StringBuilder.<init></init>或not escaped的标记 - 如果看到
arg escape，说明某个参数被判定为逃逸，可能影响标量替换
注意：该日志只在 C2 编译触发后才输出（通常需预热数千次调用），单纯执行一次 main 方法看不到结果。可配合 -XX:CompileThreshold=10 加速编译，但仅用于测试。
用 -XX:+PrintEliminateAllocations 确认分配是否真被消除
PrintEscapeAnalysis 只告诉你“逃不逃逸”，而 PrintEliminateAllocations 才告诉你“有没有消掉”：
- 启用
-XX:+UnlockDiagnosticVMOptions -XX:+PrintEliminateAllocations - 若某段代码本应分配对象但日志中无对应
alloc行，且逃逸分析显示not escaped，基本可确认标量替换已生效 - 典型失败场景：对象含 final 字段但被反射修改、数组长度动态计算超过
-XX:EliminateAllocationArraySizeLimit默认值（64）、使用了 Unsafe.allocateInstance
注意：该选项仅对 C2 编译后的方法有效；且若对象被拆解后字段仍需堆分配（比如字段本身是未逃逸的数组），则不会显示“eliminated”，而是部分优化。
为什么有时候关掉逃逸分析反而更快
逃逸分析本身有运行时开销：C2 编译器需额外做数据流分析，尤其在方法多、对象图复杂时，分析耗时可能超过优化收益：
- 高吞吐低延迟场景（如金融交易核心 loop），可尝试
-XX:-DoEscapeAnalysis对比吞吐变化 - 频繁创建短生命周期对象但逃逸路径不可预测（如 JSON 解析中的临时容器），禁用后反而减少编译卡顿
- Java 17+ 中某些逃逸判定逻辑更激进，旧代码在升级后可能出现意外逃逸，此时关闭是快速回归手段
真正难的不是“怎么开”，而是理解哪些对象在真实流量下会因分支跳转、异常路径或第三方库调用而意外逃逸——这往往需要 jstack + jmap -histo + GC 日志交叉验证，而不是单靠一个参数。
