逃逸分析（栈上分配/同步省略/标量替换）

逃逸分析：JIT 编译器的「火眼金睛」

逃逸分析（Escape Analysis）是 HotSpot JIT 编译器的一种优化技术。它分析对象的动态作用域——即对象在哪个范围内被引用——来判断对象是否会「逃逸」出某个范围。

如果一个对象不会逃逸，JIT 就可以做出一些激进的优化：栈上分配、同步省略、标量替换。

逃逸的三种级别

1. 不逃逸（No Escape）

对象只在当前方法中创建和使用，没有传递到方法外部。

public class NoEscape {
    static Point compute() {
        Point p = new Point(1, 2);  // 只在这个方法里使用
        return p;  // 等等，return p 就是把引用传出了方法！
    }
}

上面的例子是会逃逸的（返回值带走了引用）。真正不逃逸的例子：

public class NoEscape {
    static int compute() {
        Point p = new Point(1, 2);  // p 在方法内创建
        return p.x + p.y;  // 只读取字段值，不返回对象本身
        // p 没有逃逸，可以在栈上分配
    }
}

2. 方法逃逸（Method Escape）

对象作为参数传递给其他方法，或者被其他方法持有引用。

public class MethodEscape {
    static void methodEscape() {
        Point p = new Point(1, 2);
        saveToCache(p);  // p 逃逸到了 saveToCache 方法
        // 可能在别的地方被使用
    }

    static void saveToCache(Point p) {
        // p 作为参数传入，其引用被 cache 持有
        // p 逃逸了
    }
}

3. 线程逃逸（Thread Escape）

对象被其他线程访问（如存入静态变量、共享集合）。

public class ThreadEscape {
    static Point globalPoint;  // 线程逃逸！

    static void threadEscape() {
        globalPoint = new Point(1, 2);  // 存入静态变量
        // 所有线程都能看到这个对象，逃逸了
    }
}

三大优化

优化一：栈上分配（Stack Allocation）

如果对象不逃逸，JIT 编译器可以让它在栈上分配，而不是堆上。

传统方式（堆分配）：
  new Point(1, 2) → Eden 区分配 → Minor GC 后存活 → Survivor → 老年代 → GC

栈上分配：
  new Point(1, 2) → 当前线程的栈帧分配 → 方法返回时自动销毁
                      → 不需要 GC 回收

栈上分配的对象在方法返回时自动销毁，不需要垃圾回收——这是最理想的内存管理方式。

public class StackAllocation {
    public static void main(String[] args) {
        long start = System.nanoTime();
        for (int i = 0; i < 10_000_000; i++) {
            allocate();
        }
        long end = System.nanoTime();
        System.out.println("Cost: " + (end - start) / 1_000_000 + " ms");
    }

    static void allocate() {
        // 如果 JIT 逃逸分析确定 Point 不逃逸
        // 它会在栈上分配（寄存器或栈帧局部变量）
        // 不会有堆分配，也不会触发 GC
        Point p = new Point(i, i + 1);
        int sum = p.x + p.y;
        // 方法返回时，p 自动「回收」
    }
}

注意：HotSpot 实际上没有实现完整的栈上分配，但它实现了更精细的标量替换，达到了类似效果。

优化二：同步省略（锁消除 Lock Elision）

如果 JIT 分析确定一个对象只被一个线程访问，会自动消除该对象上的所有同步操作。

public class LockElision {
    public static void main(String[] args) {
        for (int i = 0; i < 1_000_000; i++) {
            compute();
        }
    }

    static void compute() {
        // counter 对象只在这个方法中使用
        // JIT 分析确定它不逃逸
        // 自动消除 synchronized
        Counter counter = new Counter();
        synchronized (counter) {  // ← JIT 会把这个 synchronized 去掉
            counter.value++;
        }
    }

    static class Counter {
        int value;
    }
}

javap -c 可以看到原始字节码中的 monitorenter/monitorexit（同步指令），但 JIT 编译后的本地代码中这些指令会被消除。

优化三：标量替换（Scalar Replacement）

如果一个对象不逃逸，JIT 可以把它拆解成多个标量（基本类型）直接存在寄存器或栈帧中，而不需要真正分配一个对象。

public class ScalarReplacement {
    static int compute() {
        // JIT 可能把这个 Point 拆解成两个 int
        // x → 局部变量 slot 1
        // y → 局部变量 slot 2
        Point p = new Point(1, 2);  // 根本不会分配 Point 对象！
        return p.x + p.y;             // 直接使用两个 int
    }
}

标量替换后：

// JIT 优化后的等价代码
static int compute() {
    int x = 1;  // Point.x 的值
    int y = 2;  // Point.y 的值
    return x + y;  // 直接用标量计算
}

这样既没有对象分配，也没有 GC。

逃逸分析的开启与验证

# 逃逸分析默认是开启的（ JDK 8+）
# 如果需要确认：
java -XX:+PrintEscapeAnalysis MyApp

# 同步省略信息
java -XX:+PrintEliminateLocks MyApp

# 标量替换信息
java -XX:+PrintScalarReplacement MyApp

逃逸分析的局限性

1. 逃逸分析本身也有开销

逃逸分析需要在 JIT 编译时进行，这本身需要消耗 CPU 时间。如果函数只运行一次（JIT 还没来得及编译），逃逸分析没有意义。

2. HotSpot 的栈上分配是「伪实现」

HotSpot 实际上没有真正实现栈上分配。它的实现策略是：

不逃逸的对象
      │
      ▼
标量替换（直接用标量）
      │
      ├── 能替换 → 不分配对象，直接用标量
      │
      └── 不能替换（如对象被返回）→ 正常堆分配

也就是说，HotSpot 用标量替换替代了栈上分配，达到了相同的效果。

3. 只在 JIT 编译后生效

解释执行和第一次 JIT 编译时，逃逸分析不生效。只有经过 JIT 充分编译优化后，才会有明显效果。

本节小结

逃逸分析是 JIT 编译器的重要优化：

优化	条件	效果
栈上分配	HotSpot 实际用标量替换实现	无堆分配，无 GC
同步省略	对象不逃逸出线程	消除不必要的 synchronized
标量替换	对象不逃逸	拆解成基本类型，不分配对象

逃逸分析让 Java 在某些场景下能达到接近 C/C++ 的内存分配性能——不需要手动管理内存，同时享受自动优化的红利。

下一节，我们来看 MinorGC/MajorGC/FullGC 对比。