Java逃逸分析是JVM在JIT编译热点方法时，通过追踪对象动态引用路径判断其是否逃逸出当前方法或线程的技术；仅当对象未逃逸（不被外部访问、不返回、不传参保存）时，才可能触发栈上分配与标量替换，使对象字段直接分配在栈帧或寄存器中，免GC、提性能。
Java 中的对象默认分配在堆上，这是常识；但逃逸分析让 JVM 有能力判断：某个对象是否真的“需要”堆空间。如果它生命周期短、作用域封闭、不被外部访问，JVM 就可能跳过堆分配，直接在栈上处理——这不是语法层面的改变，而是 JIT 编译器在运行时做的深度优化。
逃逸分析的核心判断逻辑
逃逸分析不是静态检查代码写法，而是在方法被 JIT 编译为热点代码时，对对象的**动态引用路径**做数据流追踪。关键看三点：
- 对象是否被赋值给静态变量、实例变量（→ 可能被其他线程访问）
- 对象是否作为返回值传出当前方法（→ 可能被调用方长期持有）
- 对象是否作为参数传入其他方法，且该方法可能保存其引用（如放进集合、缓存、回调等）
只要以上任一情况成立，对象就被判定为“逃逸”，必须走堆分配；全部不成立，则进入无逃逸范畴，具备栈上分配的前提条件。
栈上分配不是直接把对象塞进栈帧
很多人误以为“栈上分配 = 把整个对象结构复制到栈内存”。实际过程更精细：
- JIT 先确认对象无逃逸，且类型可分解（即不含 native 方法、finalizer、或不可见字段）
- 接着触发标量替换：把对象拆成若干基础字段（int、long、Object 引用等），这些字段各自独立分配在栈帧的局部变量表中，甚至可能被寄存器缓存
- 对象头、对齐填充、GC 标记位等堆专属开销全部消失，内存布局更紧凑，访问更快
所以“栈上分配”本质是“栈上标量分配”，它不依赖虚拟机栈的原始结构，而是编译器重写的内存布局策略。
为什么栈上分配能降低 GC 压力
堆上的对象要等 GC 触发后，经可达性分析、标记、清除/复制/整理才能回收；而栈上分配的对象：
- 随方法调用自然入栈，随方法返回自动出栈
- 栈帧销毁时，所有字段占用的空间立即归还，无需任何 GC 干预
- 尤其适合高频创建的小对象（如临时 DTO、循环内 builder、计算中间结果）
比如一个只在 for 循环里 new 的 Point 对象，若未逃逸，它不会出现在 Eden 区，也就不会触发 Young GC —— 这是从源头减少垃圾，而非加速回收。
实际开发中如何配合逃逸分析
你无法强制某个对象一定栈上分配，但可以避免破坏它的前提条件：
- 避免把局部对象赋值给 this.field 或 static field
- 慎用 return new Xxx()，尤其在工具方法中；优先用参数复用或 builder 模式内部构造
- 减少将局部对象传给不确定行为的方法（如 Collections.sort(list, comparator)，若 comparator 持有该对象引用就可能逃逸）
- 注意匿名内部类和 lambda 表达式：它们可能隐式捕获局部对象并延长其作用域
开启 -XX:+DoEscapeAnalysis（JDK 6+ 默认启用）并配合 -XX:+PrintCompilation 观察热点方法是否触发了标量替换，是验证效果的直接方式。
