逃逸分析是jvm运行时对对象生命周期的精准判断，决定对象能否栈分配、标量替换或锁消除；其生效前提是对象未逃逸且方法被jit编译，逃逸状态分为无逃逸、方法逃逸和线程逃逸三级。
逃逸分析不是“开关一开就自动提速”的魔法，而是JVM在运行时对对象生命周期的精准判断——它决定一个对象能不能不进堆、不被GC管、甚至根本不用“创建对象”。真正起效的前提是：对象确实没逃逸，且方法足够热（被JIT编译）。
对象逃逸的三种状态要分清
逃逸不是“逃或不逃”的二值判断，而是有明确分级：
- 无逃逸（No Escape）：对象只在当前方法内创建、使用、销毁，没传参、没返回、没赋值给任何成员变量或静态变量。这是栈上分配和标量替换的唯一前提。
- 方法逃逸（Arg/Method Escape）：对象作为参数传给别的方法，或作为返回值交出去。即使接收方只读、不存留，JVM也必须保守处理，无法栈分配，但可能支持锁消除。
- 线程逃逸（Global/Thread Escape）：对象被赋给静态字段、被放入全局集合、或被其他线程可见（如通过线程间共享队列）。这类对象100%堆分配，逃逸分析对其无效。
栈上分配和标量替换怎么起作用
两者常一起发生，但逻辑不同：
- 栈上分配 ≠ 把整个对象搬到栈里。JVM不会在栈上构造带对象头、对齐填充的完整堆对象结构。
- 标量替换才是关键：如果对象所有字段（包括引用字段）都未逃逸，JIT会把对象“拆开”，把每个字段（int、long、reference等）当作独立局部变量，直接放进栈帧的局部变量表，甚至寄存器。
- 效果是：没有对象实例内存申请，没有GC压力，字段访问就是普通变量读写，零额外开销。
锁消除依赖逃逸分析结果
加了synchronized不代表一定上锁——只要JVM确认锁对象没逃逸出当前线程，就能安全移除同步块：
- 典型例子：方法内创建的StringBuffer，仅用于本地字符串拼接，未传出。JIT识别后直接消除所有append上的monitor enter/exit指令。
- 注意：锁消除只适用于“局部创建 + 未逃逸”的锁对象。若锁是类成员、静态字段或传入参数，逃逸分析无法保证独占性，锁不会被消除。
实际调优中要注意什么
逃逸分析默认开启（JDK7+），但它的效果高度依赖代码写法：
- 避免无意义的返回：比如private方法里new对象又return，哪怕调用方立刻丢弃，也算方法逃逸。
- 慎用集合暂存：List.add(new Obj())看似局部，但add操作可能触发对象被集合内部引用，导致逃逸。
- 静态变量是逃逸“红灯区”：哪怕只赋值一次，对象即视为全局逃逸，强制堆分配。
- 验证是否生效：用-XX:+PrintEscapeAnalysis查看分析日志，或用jstat -gc观察Minor GC次数是否显著下降。
