逃逸分析是JVM自动启用的JIT编译期分析过程，非手动开关；它基于对象是否逃逸决定栈上分配、标量替换和同步消除等优化是否生效。
逃逸分析不是开关，而是JVM自动启用的分析过程
逃逸分析（Escape Analysis）本身不是靠某个参数“打开”就能生效的独立功能，它是 HotSpot JIT 编译器在 C2 编译阶段自动执行的代码分析行为——只要用了 Server 模式（即默认的 -server 或现代 JDK 的分层编译），它就在后台运行。你不需要手动开启它来“启用优化”，但某些优化效果是否落地，取决于它分析出的结果是否满足条件。
常见误解是：加了 -XX:+DoEscapeAnalysis 就能“强制开启逃逸分析”。实际上从 JDK 8u60 起该参数已默认开启且不可关闭；JDK 17+ 中它甚至被彻底移除。强行加上只会被忽略，还可能干扰 JVM 参数校验逻辑。
- 真正影响优化落地的是对象是否“不逃逸”：比如
new Object()只在方法内创建、没被 return、没传给其他方法、没赋值给静态/实例字段、没被锁住后暴露引用 - 逃逸分析只对热点代码有效：冷代码走解释执行，不会触发 JIT 编译，也就没有逃逸分析和后续优化
- 它不改变字节码：.class 文件里该 new 还是 new，该 synchronized 还是 synchronized；所有优化都发生在运行时 JIT 编译阶段，对 class 文件完全透明
栈上分配只对“方法局部 + 不逃逸”的对象生效
所谓“对象分配在栈上”，本质是 JIT 编译器判断：这个对象生命周期完全绑定在当前方法栈帧里，连堆都不用进。但它不是内存分配策略的优先级选择（比如比 TLAB 更高），而是一种“可选消除”——如果逃逸分析证明可以不用堆，就干脆不分配堆内存。
典型误用场景：把一个 ArrayList 声明在方法里，但往里面 add 了外部传入的引用，或调用了 toArray() 返回出去——哪怕没显式 return 对象本身，只要字段引用逃逸，整个对象就算逃逸。
- 只有无状态、轻量、字段可全量拆解的对象才容易被栈上分配，比如
Point、Pair、自定义小 DTO - 含 final 字段、无同步块、无虚方法调用（避免多态导致分析失效）更利于逃逸判定
- 别指望大对象（如
byte[1024]）被栈上分配：JVM 对栈上分配有大小阈值限制（默认约几 KB），超限直接回退到堆 + TLAB
标量替换不是“拆对象”，而是“跳过对象创建”
标量替换（Scalar Replacement）常被说成“把对象拆成字段”，但这容易误导。它的真实含义是：当逃逸分析确认对象不逃逸且可分解时，JIT 直接不生成该对象实例，而是把它的字段当成局部变量处理——比如 point.x 和 point.y 变成两个独立的 int 局部变量，存在栈上甚至寄存器里。
这意味着：你代码里写的 new Point(1, 2)，实际运行时可能根本没调用 Point 的构造器，也没在内存里形成对象头、klass 指针等结构。
- 开启标量替换需配合逃逸分析，默认已启用；可通过
-XX:+PrintEliminateAllocations查看哪些对象被成功替换 - 只要对象里有任何字段是对象引用（哪怕只是
String），且该引用无法被进一步证明不逃逸，整个标量替换就会失败 - final 字段不是必须的，但非 final 字段若在构造后被修改，可能破坏 JIT 对字段生命周期的推断，导致替换失败
同步消除只消“无竞争的锁”，不碰“语义正确的 synchronized”
同步消除（Lock Elimination）不是删掉 synchronized 关键字，而是 JIT 发现：这个锁对象（比如 new Object()）的生命周期严格限定在线程内，不可能被其他线程拿到，那加锁就纯属冗余——于是直接把 monitor enter/exit 指令干掉。
典型例子：synchronized(new Object()) { ... } 在方法内部创建并立即加锁，这种代码 JIT 几乎必消；但如果你锁的是 this、静态对象、或方法参数传进来的对象，基本不会消——因为逃逸分析无法证明它们不被共享。
- 同步消除默认开启，对应参数是
-XX:+EliminateLocks（JDK 8+ 默认 true） - 它只作用于“对象锁”，对
ReentrantLock.lock()等显式锁无效——那是库代码，JIT 不介入 - 即使锁被消除，字节码仍保留
synchronized块结构；你用javap看不到变化，得用-XX:+PrintCompilation或 JFR 观察编译后代码
逃逸分析真正的复杂点不在参数怎么配，而在于它高度依赖代码模式和运行时热度：同一段代码，在测试环境跑得慢没被 JIT 编译，就看不到任何优化；上线后变热点，所有优化突然生效——但你也很难复现和调试。所以别对着开发机狂加参数调优，先确保它真跑在 C2 编译路径上，再看日志里有没有 eliminated、stack allocated 这类关键词。
