什么是逃逸分析？对象一定分配在堆上吗？

简化版

逃逸分析（Escape Analysis）是 JIT 的一项优化技术，用来判断一个对象的作用域有没有「逃逸」出当前方法或线程。如果一个对象只在方法内部使用、不会被外部引用（没逃逸），JVM 就能做三种优化：① 栈上分配——把对象直接建在栈上，随方法结束自动销毁，不进堆、不需要 GC；② 标量替换——干脆不创建对象，把它的字段拆成一个个局部变量；③ 锁消除——如果对象不会被多线程共享，它身上的同步锁直接去掉。所以「对象一定在堆上分配」是错的——经过逃逸分析优化的未逃逸对象可能根本不进堆。

详细版

什么叫「逃逸」：

方法逃逸：对象被方法外部引用（作为返回值、赋值给成员变量、传给别的方法…）
线程逃逸：对象被其他线程访问（赋值给静态变量、实例被多线程共享…）

未逃逸：对象的生命周期完全在方法内，外部拿不到它的引用

// 未逃逸：sb 只在方法内用，外部拿不到 → 可优化
String concat(String a, String b) {
    StringBuilder sb = new StringBuilder();  // 没逃逸
    sb.append(a).append(b);
    return sb.toString();   // 返回的是 String，sb 本身没逃逸出去
}

// 逃逸：对象被返回，外部能引用 → 不能优化
StringBuilder create() {
    StringBuilder sb = new StringBuilder();
    return sb;   // sb 逃逸了（作为返回值出去）
}

三种优化：

优化	条件	效果
栈上分配	对象未逃逸出方法	对象建在栈帧上，方法结束随栈弹出，无需 GC
标量替换	对象未逃逸且可拆解	不创建对象，字段变成独立局部变量（放寄存器/栈）
锁消除	对象未逃逸出线程	去掉不可能有竞争的同步锁

// 锁消除示例：sb 是局部变量，不可能被多线程访问
// StringBuffer.append 内部有 synchronized，但 JIT 发现无竞争 → 消除锁
StringBuffer sb = new StringBuffer();  // 局部，未逃逸
sb.append("a").append("b");            // synchronized 被 JIT 消除

⚠️ 逃逸分析是 JIT 的运行时优化，默认开启（-XX:+DoEscapeAnalysis）。它不保证一定发生——是否优化取决于 JIT 的判断，且解释执行时不生效（要代码热到被 JIT 编译才可能触发）。所以「栈上分配」是一种可能的优化，不是语言保证。

完整版教学

一、破除误解：对象不一定在堆上

Java 教科书常说「对象在堆上分配、基本类型在栈上」，这是简化的默认模型，不是绝对。经过 JIT 逃逸分析优化后，一个「没逃逸」的对象可能：根本不进堆（栈上分配），甚至根本不作为对象存在（标量替换，被拆成几个局部变量）。

默认认知：new 一个对象 → 堆上分配 → 靠 GC 回收
真实情况（JIT 优化后）：
  对象没逃逸 → 可能栈上分配（随方法栈帧销毁，零 GC 压力）
           → 甚至标量替换（连对象都不建，字段直接当局部变量）

为什么这很重要？因为堆分配 + GC 是有成本的。如果大量「短命、方法内用完就丢」的对象都能不进堆，就能大幅减轻 GC 压力、提升性能。逃逸分析就是让 JVM 识别这类对象并优化的技术。理解「对象不一定在堆上」，是理解 JVM 性能优化的关键一步。

二、逃逸的两个层次：方法逃逸与线程逃逸

「逃逸」指对象的引用「跑出了」它的作用域，分两个层次：

无逃逸：对象只在方法内使用，外部完全拿不到引用
  → 可做全部三种优化

方法逃逸：对象被方法外部拿到（返回值/赋给字段/传参给其他方法）
  → 不能栈上分配（方法结束后外部还要用它）

线程逃逸：对象被其他线程访问（赋给静态变量/实例字段被多线程读）
  → 连锁都不能消除（真的可能有并发竞争）

逃逸程度越低，能做的优化越多。判断逻辑：这个对象的引用，会不会流出当前方法/线程的边界？ 流出了就逃逸、优化受限；没流出就能激进优化。JIT 通过数据流分析追踪每个对象引用的去向来判断。

三、栈上分配：让短命对象随栈消亡

如果对象没逃逸出方法，JIT 可以把它分配在当前方法的栈帧上，而不是堆：

堆分配：new 对象 → 堆 → 方法结束对象还在 → 等 GC 回收（有成本）
栈分配：new 对象 → 当前栈帧 → 方法结束栈帧弹出 → 对象自动消失（零 GC）

好处显而易见：栈上对象随方法调用结束自动销毁，完全不需要 GC 介入。想象一个高频调用的方法，每次都 new 一个临时对象——如果都栈上分配，GC 压力几乎为零。用数字感受：一个方法每秒调用 100 万次、每次 new 一个 32 字节对象，堆分配就是每秒 32MB 的垃圾要 GC；栈上分配则这 32MB 压力全部消失。这是逃逸分析最直接的性能收益。（注：HotSpot 实际主要通过「标量替换」实现这个效果，而非严格意义的栈上分配。）

四、标量替换：连对象都不创建

比栈上分配更激进的是标量替换（Scalar Replacement）——如果对象没逃逸且能被拆解，JIT 干脆不创建这个对象，把它的字段当成一个个独立的局部变量（标量）：

class Point { int x, y; }
int compute() {
    Point p = new Point();   // 未逃逸
    p.x = 1;
    p.y = 2;
    return p.x + p.y;
}
// 标量替换后，JIT 实际生成的代码近似：
int compute() {
    int x = 1;   // 不再有 Point 对象！
    int y = 2;   // p.x、p.y 变成两个独立局部变量
    return x + y;
}

「标量」指不可再分的基本类型（int、long 等），「聚合量」是对象。标量替换就是把聚合量拆成标量，这些局部变量可以直接放进 CPU 寄存器，比访问堆内存快得多。这是比栈上分配更彻底的优化——不仅不进堆，连「对象」这个概念都消失了。HotSpot 里逃逸分析的「栈上分配」效果，很大程度就是靠标量替换实现的。

五、锁消除：去掉没有竞争的锁

第三种优化针对同步。如果一个加了锁的对象没有逃逸出线程（不可能被多线程访问），那它身上的锁就是多余的，JIT 直接消除：

public String concat(String a, String b) {
    StringBuffer sb = new StringBuffer();  // 局部变量，只有当前线程能访问
    sb.append(a).append(b);   // StringBuffer.append 是 synchronized 的
    return sb.toString();
}
// JIT 逃逸分析发现 sb 不可能被其他线程访问（未线程逃逸）
// → append 里的 synchronized 锁没有任何竞争 → 直接消除，当作无锁执行

这解释了一个反直觉现象：用 StringBuffer 做局部拼接，性能不一定比 StringBuilder 差多少——因为 JIT 会把 StringBuffer 里那些没竞争的锁消除掉。锁消除让「防御性加锁」的代码在确实无竞争时不付出锁的代价。但它依赖逃逸分析准确判断「真的没有线程逃逸」，所以只对局部、未共享的对象生效。

六、逃逸分析的局限与实践

逃逸分析虽好，但有几个必须知道的限制：

① 是 JIT 优化，不是语言保证：
   解释执行时不生效；只有代码热到被 JIT 编译才可能触发
② 分析有成本：JIT 要做数据流分析，太复杂的对象/方法可能放弃优化
③ 不是所有未逃逸对象都会被优化：JIT 有自己的启发式判断
④ 大对象、数组通常不做标量替换

实践建议：别为了「触发栈上分配」去写奇怪的代码——逃逸分析是 JVM 自动做的，你只要写正常的、对象作用域尽量小的代码，JIT 自然会优化。真正能主动利用的是「把对象作用域限制在方法内」（别无谓地把局部对象暴露成成员变量或返回出去），给 JIT 创造优化空间。相关参数：-XX:+DoEscapeAnalysis（默认开）、-XX:+EliminateAllocations（标量替换）、-XX:+EliminateLocks（锁消除）。

记忆钩子：「逃逸分析判断对象跑没跑出方法/线程；没逃逸 → 栈上分配（随栈销毁无 GC）、标量替换（拆成局部变量连对象都不建）、锁消除（去掉无竞争的锁）；所以对象不一定在堆上，但这是 JIT 优化不是保证」。

七、常见误区与追问

误区：Java 对象一定分配在堆上。 经逃逸分析优化的未逃逸对象可能栈上分配、甚至标量替换（连对象都不建），不进堆、不需要 GC。
误区：逃逸分析能保证栈上分配。 它是 JIT 运行时优化，默认开但不保证一定发生——解释执行不生效，是否优化取决于 JIT 判断。
误区：栈上分配是 HotSpot 的独立机制。 HotSpot 实际主要靠「标量替换」达到栈上分配的效果，并非严格实现了独立的「栈上分配对象」。
误区：局部 StringBuffer 一定比 StringBuilder 慢很多。 JIT 会对未线程逃逸的 StringBuffer 做锁消除，把 synchronized 去掉，实际差距很小。
追问：什么是标量替换？ 未逃逸且可拆解的对象，JIT 不创建它，把其字段拆成独立的局部变量（标量），可放寄存器，比堆访问快，是比栈上分配更彻底的优化。
追问：逃逸分析和锁消除的关系？ 锁消除依赖逃逸分析——只有确认对象没有「线程逃逸」（不可能被多线程访问），才能安全地消除它身上的同步锁。
追问：怎么给 JIT 创造逃逸优化的空间？ 把对象作用域尽量限制在方法内（别无谓地暴露成成员变量或返回出去），写正常代码即可，逃逸分析会自动优化短命局部对象。

八、加强记忆

逃逸分析是 JIT 判断「对象的引用有没有跑出当前方法/线程边界」的技术，据此做三种优化：① 栈上分配——未逃逸出方法的对象直接建在栈帧上，随方法结束自动销毁、零 GC 压力；② 标量替换——更激进，未逃逸且可拆的对象干脆不创建，字段拆成独立局部变量（可进寄存器），HotSpot 的「栈上分配」效果主要靠它；③ 锁消除——未逃逸出线程（不可能被多线程访问）的对象，身上的同步锁直接去掉（所以局部 StringBuffer 的锁会被消除）。这直接打破「对象一定在堆上」的误解——未逃逸对象可能根本不进堆、甚至不作为对象存在。但要牢记它是 JIT 的运行时优化、不是语言保证（解释执行不生效、要代码变热被编译才可能触发）。实践上别写怪代码去「凑」优化，只要把对象作用域限制在方法内，就给了 JIT 优化空间。一句话「逃逸分析看对象跑没跑出去，没跑出去就栈上分配/标量替换/锁消除，对象未必在堆上但这是 JIT 优化非保证」。

简化版

详细版