逃逸分析本身不直接移动对象，仅判断其是否逃逸出方法或线程；只有确认不逃逸时，才触发标量替换等优化，将对象拆解为字段存于栈或寄存器，彻底规避堆分配与GC开销。
逃逸分析本身不直接移动对象，它只是判断一个对象是否“逃逸”出当前方法或线程。只有当编译器确认对象不会逃逸，才会触发后续优化——其中标量替换就是最彻底的一种：把整个对象拆开，用它的字段（比如 int age、String name）分别存在栈上，甚至寄存器里，完全绕过堆分配。
标量替换的前提：对象必须“不逃逸”
对象只要出现以下任一情况，就无法被标量替换：
- 被赋值给类的成员变量（如 this.p = new Person()）
- 作为参数传入其他方法（哪怕只是 print(person)）
- 被放入静态集合、全局缓存或线程共享容器中
- 被 synchronized 块锁定（可能引发锁竞争，影响逃逸判定）
只要没这些行为，JIT 就大概率把它当作“纯局部变量”处理。
标量替换的实际效果：没有对象，只有字段
假设你写：
public int calc() {
Person p = new Person(28, "Alice");
return p.age * p.name.length();
}如果 Person 没逃逸，JIT 可能将它拆解为两个独立变量：
- int age = 28（直接压栈或进寄存器）
- String name = "Alice"（字符串常量池引用，也放栈上）
连对象头、内存对齐、GC 标记这些开销都消失了，执行效率接近手写基本类型运算。
JVM 默认已开启，但有隐性限制
HotSpot 在 JDK 8u60+ 后默认启用相关优化：
- -XX:+DoEscapeAnalysis（逃逸分析）
- -XX:+EliminateAllocations（标量替换）
- -XX:+UseTLAB（配合提升局部分配效率）
不过要注意：标量替换只对“可分解”的对象生效。如果 Person 里包含未逃逸的数组、嵌套对象或 final 字段引用不可变对象，JIT 仍可能尝试进一步拆解；但如果字段本身是复杂对象且存在逃逸风险，就会退回到栈上分配或干脆堆分配。
怎么验证是否发生了标量替换？
加 JVM 参数观察日志：
- -XX:+PrintEscapeAnalysis：打印逃逸分析结果
- -XX:+PrintOptoAssembly（需 hsdis）：查看汇编，确认是否还有对象创建指令
- 对比 GC 日志：标量替换后，对应对象不会出现在 Eden 区分配统计中
实际压测时，若局部高频创建小对象的函数吞吐明显上升、GC 暂停减少，往往就是标量替换在起作用。
