#逃逸分析与栈上分配

候选人小吴在面试字节 P7 时，面试官问道：

"什么是逃逸分析？什么情况下对象会逃逸？"

小吴说："逃逸分析就是判断对象的作用域..."面试官追问："逃逸分析后，对象可以不分配在堆上吗？"

小吴答不上来。面试官继续追问："标量替换是什么？"

小吴彻底卡住了...

#一、核心问题：逃逸分析 🔴

#1.1 问题拆解

第一层：逃逸定义（什么是逃逸？）
  "什么情况下对象会逃逸？"
  考察点：方法逃逸、线程逃逸

第二层：栈上分配（怎么优化？）
  "逃逸分析后，对象会怎么优化？"
  考察点：栈上分配、标量替换

第三层：同步消除（怎么优化？）
  "synchronized 在逃逸分析后怎么处理？"
  考察点：锁消除

#1.2 ❌ 错误示范

候选人原话 A："逃逸分析后，所有对象都分配在栈上。"

问题诊断：栈上分配只是逃逸分析的一种优化手段。更常见的优化是标量替换，而不是真正的栈上分配。

候选人原话 B："逃逸分析是解释执行时做的。"

问题诊断：逃逸分析是 JIT 编译器 在编译时做的，不是解释执行时。解释执行没有足够的信息做逃逸分析。

#1.3 标准回答

#P5 级别：逃逸的定义

逃逸分析（Escape Analysis）：

逃逸分析是 JIT 编译器在编译时分析对象的动态作用域，判断对象是否"逃逸"出当前执行上下文。

逃逸的两种类型：

类型	定义	示例
方法逃逸	对象作为方法返回值被外部方法持有	return obj
线程逃逸	对象被其他线程持有引用	static Object obj; obj = new Object()

不逃逸的对象：

public void method() {
    Object local = new Object();  // 对象不逃逸（只在方法内使用）
    // ... 使用 local
}  // 方法结束后，local 不再可达

方法逃逸的例子：

public Object method() {
    Object obj = new Object();  // 逃逸：作为返回值
    return obj;
}

public static Object staticObj;  // 线程逃逸
public void setStatic() {
    staticObj = new Object();  // 线程逃逸
}

#P6 级别：优化技术

逃逸分析的三大优化：

graph TD
    A[逃逸分析] --> B[栈上分配<br/>对象在栈上分配而非堆]
    A --> C[标量替换<br/>对象字段拆解为局部变量]
    A --> D[锁消除<br/>synchronized 锁无效]

1. 栈上分配（Stack Allocation）：

如果对象不逃逸，可以将对象分配在线程栈上，而不是堆：

// 优化前
void method() {
    Object obj = new Object();  // 在堆上分配
}

// 优化后（理想情况）
void method() {
    // 对象不分配在堆中，而是用局部变量替代
    // 在方法栈帧中直接创建
}

但 HotSpot 实际上不实现栈上分配。HotSpot 使用标量替换替代了栈上分配。

2. 标量替换（Scalar Replacement）：

如果对象不逃逸，JIT 编译器会将对象的字段替换为独立的局部变量（标量）：

// 源代码
class Point {
    int x;
    int y;
}

void method() {
    Point p = new Point();
    p.x = 1;
    p.y = 2;
    System.out.println(p.x + p.y);
}

// JIT 编译后的优化（标量替换）
void method() {
    int x = 1;  // 替换 p.x
    int y = 2;  // 替换 p.y
    System.out.println(x + y);  // 无需创建 Point 对象
}

3. 锁消除（Lock Elision）：

如果对象不逃逸出当前线程，synchronized 锁可以被消除：

void method() {
    Object obj = new Object();
    synchronized (obj) {  // 如果 obj 不逃逸，锁可以被消除
        // ...
    }
}

#P7 级别：逃逸分析的限制

逃逸分析的限制：

1. JIT 编译时才生效：逃逸分析是 JIT 编译阶段做的，解释执行时不生效

2. 分析开销：逃逸分析本身有编译开销，所以 JVM 不会对所有方法都做完整的逃逸分析

3. 复杂性：复杂的调用图可能导致逃逸分析无法精确判断

HotSpot 的实际实现：

HotSpot 的逃逸分析（JIT 编译器 C2）会将分析结果用于：

• 标量替换
• 锁消除

但 HotSpot 不实现栈上分配，因为标量替换已经达到了相同的效果（对象不在堆上分配），而且更容易实现。

启用逃逸分析：

-XX:+DoEscapeAnalysis  # JDK 8 默认开启
-XX:-DoEscapeAnalysis  # 关闭逃逸分析

【面试官心理】 这道题我能问到 P7 级别，是因为逃逸分析涉及了 JIT 编译优化、标量替换等高级概念。能说清 HotSpot 不实现栈上分配而用标量替换替代的候选人说明他理解了 JVM 的实现权衡。

#1.4 追问升级

追问：逃逸分析和 G1 的关系？

G1 的 region 结构和逃逸分析没有直接关系。逃逸分析是在 JIT 编译阶段做的，G1 是 GC 算法。两者是正交的。

#二、生产避坑 🟢

#2.1 逃逸分析的观察

# 查看 JIT 编译日志
-XX:+PrintCompilation  # 打印 JIT 编译信息

# 查看 GC 日志
-XX:+PrintGCDetails

#2.2 逃逸分析的常见误解

• 逃逸分析不会在所有方法上生效（需要被 JIT 编译）
• HotSpot 标量替换后，对象根本不在堆上分配
• 逃逸分析只对 JIT 编译后的代码生效