JIT 逃逸分析：对象为什么可能不真正分配到堆上

先记住一句核心结论：

Java 语义上 new 了对象，但 HotSpot JIT 经过逃逸分析后，可能发现这个对象只在方法内部使用，外部永远拿不到它，于是直接消除对象分配，或者把对象拆成几个普通变量。这样运行时就不一定真的在堆上创建完整对象。

这句话很容易被误解成“Java 对象会被分配到栈上”。更准确的说法是：

大多数对象确实在堆上分配。
少数热点代码中的短命对象，JIT 可能通过逃逸分析证明它不会逃出当前作用域。
如果对象不逃逸，JIT 可能做标量替换，把对象字段拆成局部变量、寄存器值或栈帧里的临时值。
最终效果是：代码里有 new，但机器码里可能没有真正的堆分配。

学习目标

目标	说明
知道是什么	理解逃逸分析判断对象引用是否逃出方法或线程
知道为什么	理解为什么减少堆分配可以降低 GC 压力
知道怎么工作	理解不逃逸、方法逃逸、线程逃逸、标量替换、锁消除
知道不这样会怎样	知道大量临时对象进入堆会导致 Eden 压力和 GC 增加
会看代码	能判断哪些写法更容易被优化，哪些写法会阻止优化
会面试	能准确回答“对象一定在堆上吗”“逃逸分析和栈上分配是什么关系”

为什么要有逃逸分析

对象分配虽然在 JVM 里已经很快，尤其有 TLAB 后，线程可以在 Eden 的线程本地分配缓冲区中快速分配对象。但它仍然不是免费的：

成本	说明
分配成本	Eden 指针移动、TLAB 不足时慢路径分配
初始化成本	对象内存要置零，对象头要设置
GC 成本	对象进入堆后，后续 GC 需要处理它
缓存成本	大量短命对象会增加内存带宽和 CPU cache 压力

这里要特别区分 TLAB 和逃逸分析：

概念	本质	对象是否还在堆里
TLAB	Eden 区中划给线程的私有分配缓冲区	在，仍然是真实堆对象
逃逸分析	JIT 判断对象引用是否逃出作用域	不一定，可能被标量替换或分配消除

TLAB 解决的是“多个线程同时在堆上分配对象时如何减少竞争”；逃逸分析解决的是“这个对象有没有必要真的创建完整堆对象”。所以 TLAB 不是栈上分配，对象进入 TLAB 也不代表它不受 GC 管理。

大量业务代码会创建非常短命的对象：

java

public int calculate(int price, int count) {
    Money money = new Money(price, count);
    return money.total();
}

如果 money 只在 calculate 方法内部使用，方法返回后外部也拿不到它，那么真的创建一个完整堆对象再马上回收，就有点浪费。

JIT 的逃逸分析就是为了回答：

这个对象会不会被方法外部或其他线程访问到？

如果答案是“不会”，JIT 就有机会优化掉这次分配。

逃逸是什么意思

“逃逸”不是异常，也不是内存泄漏。它指的是对象引用逃出了某个分析范围。

常见层级：

类型	含义	优化空间
不逃逸	对象只在当前方法内部使用	最容易标量替换、分配消除
方法逃逸	对象被返回，或传给外部无法内联分析的方法	较难消除分配
线程逃逸	对象被其他线程可能访问，例如写入静态变量、实例字段、共享集合	基本不能当作线程私有对象优化

mermaid

flowchart TD
    A["new 对象"] --> B{"引用是否离开当前方法"}
    B -- "没有" --> C["不逃逸"]
    B -- "返回或传给外部方法" --> D["方法逃逸"]
    B -- "写入共享字段或其他线程可见位置" --> E["线程逃逸"]
    C --> F["可能分配消除或标量替换"]
    D --> G["优化空间变小"]
    E --> H["通常必须保留真实对象和同步语义"]

不逃逸示例

java

public class NoEscapeDemo {
    static class Point {
        int x;
        int y;

        Point(int x, int y) {
            this.x = x;
            this.y = y;
        }
    }

    public static int distance() {
        Point point = new Point(3, 4);
        return point.x * point.x + point.y * point.y;
    }

    public static void main(String[] args) {
        int sum = 0;
        for (int i = 0; i < 100_000_000; i++) {
            sum += distance();
        }
        System.out.println(sum);
    }
}

从 Java 源码看，distance() 每次都 new Point(3, 4)。

但 JIT 可能分析出：

point 没有返回。
point 没有赋值给字段。
point 没有传给无法分析的外部方法。
外部线程不可能访问到 point。
最终只用到了 x 和 y 两个 int 字段。

于是 JIT 可以把它优化成类似下面的机器逻辑：

java

public static int distanceOptimizedLike() {
    int x = 3;
    int y = 4;
    return x * x + y * y;
}

注意：这只是帮助理解的等价形式，不是 Java 源码真的被改成这样。

标量替换是什么

标量是不可再拆分的值，比如 int、long、引用地址等。对象是聚合量，因为它由多个字段组成。

标量替换就是：

如果一个对象不会逃逸，而且对象字段可以被拆开使用，JIT 可能不创建完整对象，而是把对象字段拆成若干个局部变量。

mermaid

flowchart TD
    A["Point 对象"] --> B["字段 x"]
    A --> C["字段 y"]
    B --> D["局部变量或寄存器"]
    C --> E["局部变量或寄存器"]
    D --> F["不再需要完整堆对象"]
    E --> F

这就是“对象不真正分配到堆上”的最常见解释。

更严谨地说：在 HotSpot C2 优化中，常见效果不是“把整个对象完整放到 Java 栈上”，而是通过标量替换让这个对象根本不以完整对象形态存在。

方法逃逸示例

下面对象被返回给调用方：

java

public class MethodEscapeDemo {
    static class Point {
        int x;
        int y;
    }

    public static Point createPoint() {
        Point point = new Point();
        point.x = 3;
        point.y = 4;
        return point;
    }
}

point 被返回后，调用方可能继续保存、传递、修改它。JIT 不能简单假设它只在 createPoint() 内部使用。

mermaid

flowchart TD
    A["createPoint 创建对象"] --> B["return point"]
    B --> C["调用方获得引用"]
    C --> D["可能保存到集合"]
    C --> E["可能传给其他方法"]
    C --> F["可能被其他线程看到"]

这种就是方法逃逸。方法逃逸不一定完全不能优化，如果调用链很短、方法能内联，JIT 仍可能跨方法分析；但优化难度比不逃逸更高。

线程逃逸示例

java

public class ThreadEscapeDemo {
    private static Object shared;

    public static void publish() {
        Object object = new Object();
        shared = object;
    }
}

object 被赋值给静态字段 shared，其他线程可能读取它：

java

Object value = ThreadEscapeDemo.shared;

这就是线程逃逸。线程逃逸的对象必须遵守 Java 内存模型的可见性和同步语义，JIT 不能随便把它拆掉。

常见线程逃逸写法：

写法	为什么逃逸
返回对象	调用方拿到引用
赋值给成员变量	对象生命周期超过当前方法
赋值给静态变量	全局可见
放入集合或缓存	其他代码可能拿到
传给新线程	其他线程可访问
传给无法内联的方法	JIT 不确定外部方法会不会保存引用

锁消除是什么

逃逸分析不仅能减少对象分配，还能帮助消除不必要的锁。

例如：

java

public String concat(String a, String b) {
    StringBuffer buffer = new StringBuffer();
    buffer.append(a);
    buffer.append(b);
    return buffer.toString();
}

StringBuffer 的 append 方法带同步语义。但这里 buffer 是方法内部新建的局部对象，没有逃逸到其他线程，其他线程不可能竞争它的锁。

JIT 可能判断：

buffer 没有线程逃逸。
锁只会被当前线程获取。
同步没有实际竞争意义。

于是可以做锁消除。

mermaid

flowchart TD
    A["new StringBuffer"] --> B{"是否线程逃逸"}
    B -- "否" --> C["append 中的同步没有竞争"]
    C --> D["JIT 可能消除锁"]
    B -- "是" --> E["必须保留同步语义"]

这就是为什么有些看起来带锁的代码，热点运行后不一定真的有锁成本。

栈上分配到底怎么理解

很多资料会说逃逸分析可以做“栈上分配”。这个说法适合入门理解，但面试时最好讲得更严谨：

说法	准确程度	说明
对象一定在堆上	不完全准确	大多数对象在堆上，但 JIT 可能消除分配
对象会分配到栈上	容易误导	容易让人以为完整对象搬到 Java 栈
JIT 可通过逃逸分析做标量替换和分配消除	更准确	对象可能不以完整对象形式存在

你可以这样回答：

从 Java 语义和大多数运行情况看，对象主要分配在堆上。但 HotSpot JIT 对热点代码做逃逸分析后，如果证明对象不会逃逸，可能通过标量替换把对象字段拆成局部变量或寄存器值，进而消除堆分配。很多时候不是完整对象真的放到栈上，而是对象分配被优化没了。

JIT 优化不是一开始就发生

逃逸分析属于 JIT 优化，通常发生在热点代码被编译时。

mermaid

flowchart TD
    A["程序启动"] --> B["解释器先执行字节码"]
    B --> C["方法被频繁调用"]
    C --> D["达到热点阈值"]
    D --> E["JIT 编译热点方法"]
    E --> F["逃逸分析"]
    F --> G["标量替换或锁消除"]

这意味着：

代码刚启动时未必有这个优化。
执行次数太少的方法未必被 JIT 编译。
复杂控制流、反射、JNI、不可内联调用可能影响分析效果。
JVM 可以因为类加载、类型假设失效等原因反优化，也就是 deoptimization。

所以不要在业务代码里依赖“这个对象一定会被逃逸分析优化”。它是性能优化，不是语义保证。

JDK 7、JDK 8 和后续版本

企业项目里 JDK 7、JDK 8 仍然很常见，需要重点掌握。

版本	说明
JDK 7	HotSpot Server VM 中逃逸分析已是常见默认优化能力
JDK 8	企业最常见版本之一，逃逸分析、标量替换、锁消除是重要 JIT 优化点
JDK 9+	日志参数变化，JIT 和 GC 继续演进，但核心思想不变
JDK 17/21	长期支持版本中优化更成熟，但不能把某个具体优化当作 Java 语义保证

常见参数：

参数	说明
`-XX:+DoEscapeAnalysis`	开启逃逸分析，JDK 7/8 常见默认开启
`-XX:-DoEscapeAnalysis`	关闭逃逸分析，用于实验对比
`-XX:+EliminateAllocations`	允许分配消除，通常依赖逃逸分析
`-XX:-EliminateAllocations`	关闭分配消除，用于实验对比
`-XX:+EliminateLocks`	允许锁消除
`-XX:-EliminateLocks`	关闭锁消除，用于实验对比

有些资料会提 PrintEscapeAnalysis、PrintEliminateAllocations，但这些选项在普通生产版 JDK 中不一定可用，很多时候需要 debug 版 JVM，所以日常学习不要依赖它们。

Demo：对比逃逸分析开关

下面代码会大量创建短命对象，适合观察逃逸分析对 GC 的影响。

java

public class EscapeAnalysisDemo {
    static class OrderAmount {
        private final int price;
        private final int count;

        OrderAmount(int price, int count) {
            this.price = price;
            this.count = count;
        }

        int total() {
            return price * count;
        }
    }

    public static int calculate(int price, int count) {
        OrderAmount amount = new OrderAmount(price, count);
        return amount.total();
    }

    public static void main(String[] args) {
        long result = 0;
        for (int i = 0; i < 500_000_000; i++) {
            result += calculate(i, 2);
        }
        System.out.println(result);
    }
}

JDK 8 运行示例：

bash

javac EscapeAnalysisDemo.java
java -server -Xms128m -Xmx128m -XX:+PrintGCDetails EscapeAnalysisDemo

关闭逃逸分析再对比：

bash

java -server -Xms128m -Xmx128m -XX:-DoEscapeAnalysis -XX:+PrintGCDetails EscapeAnalysisDemo

JDK 9+ 可以用：

bash

java -Xms128m -Xmx128m -Xlog:gc* EscapeAnalysisDemo
java -Xms128m -Xmx128m -XX:-DoEscapeAnalysis -Xlog:gc* EscapeAnalysisDemo

你可能观察到：关闭逃逸分析后，GC 次数更多，运行时间更长。具体结果受 JDK 版本、CPU、JIT 编译时机影响，不同机器不一定完全一样。

什么写法更容易被优化

更容易优化：

java

public int total(int price, int count) {
    OrderAmount amount = new OrderAmount(price, count);
    return amount.total();
}

原因：

对象只在方法内部使用。
方法简单，容易内联。
字段简单，容易标量替换。
没有写入共享位置。

更难优化：

java

private OrderAmount lastAmount;

public int total(int price, int count) {
    OrderAmount amount = new OrderAmount(price, count);
    this.lastAmount = amount;
    return amount.total();
}

原因：对象保存到成员变量，生命周期可能超过当前方法，其他方法或线程可能访问。

商业项目中的理解方式

逃逸分析在真实项目中的价值是减少临时对象带来的 GC 压力。

场景	说明
接口参数组装	临时 DTO 如果不逃逸，可能被优化
循环中的小对象	如果只在循环内部参与计算，可能被消除
字符串拼接	JIT 可能优化局部 `StringBuilder` 或消除锁
金额计算临时对象	小型值对象可能被标量替换
日志参数包装	如果最终未逃逸，可能减少分配，但不能依赖

但工程上不要为了“帮助逃逸分析”写很怪的代码。更重要的是：

不要无意义创建大量对象。
不要把临时对象保存到长生命周期容器。
热点循环里避免不必要的装箱、集合、字符串拼接。
使用 JMH 做基准测试，避免被 JIT 优化误导。
线上问题先看 GC 日志、对象分配速率和火焰图。

常见误区

误区	正确理解
所有局部对象都在栈上	局部变量引用在栈帧，对象大多数仍在堆上
有逃逸分析就不会有 GC	只优化少数可证明不逃逸的热点对象
手写代码能强制对象栈上分配	Java 代码不能直接强制，JIT 自己决定
逃逸分析一定发生	只有热点代码被 JIT 编译后才有机会
对象不在堆上就能改变语义	优化必须保证 Java 语义不变
微基准里对象没分配，业务里也一定没分配	业务代码更复杂，逃逸、反射、接口调用都会影响优化

和 OOM、GC 的关系

逃逸分析可以减少一部分短命对象的堆分配，从而降低 Eden 分配压力和 Minor GC 次数。但它不能解决真正的内存泄漏。

问题	逃逸分析能否解决
方法内临时对象太多	可能缓解
大集合一直被缓存引用	不能
ThreadLocal 未清理	不能
一次查询百万行	不能
静态 Map 无限制增长	不能
大对象直接进入老年代	通常不能

如果对象已经逃逸并被长期引用，GC 就不能回收它，逃逸分析也救不了。

面试标准回答

对象不一定绝对分配在堆上。Java 语义上 new 了对象，大多数情况下对象实例确实在堆中分配。但 HotSpot JIT 对热点代码做逃逸分析时，如果能证明某个对象不会逃出方法或线程作用域，就可能进行标量替换和分配消除，把对象字段拆成局部变量或寄存器值，从而不真正创建完整堆对象。逃逸分析还可以支持锁消除，例如局部 StringBuffer 不会被其他线程访问时，同步锁可能被消除。不过这是 JIT 优化，不是 Java 语言层面的保证，不能在业务代码中依赖它。

追问回答

追问	回答
栈上分配和标量替换区别	栈上分配容易理解成完整对象放栈上；HotSpot 常见优化是标量替换，让对象不再以完整对象形式存在
什么是方法逃逸	对象被返回或传给外部方法，当前方法结束后外部仍可能访问
什么是线程逃逸	对象被其他线程可能访问，例如写入静态变量、实例字段、共享集合
为什么逃逸分析能锁消除	如果对象不会被其他线程访问，对这个对象加锁没有竞争意义
JDK 8 默认有吗	JDK 8 HotSpot Server VM 中逃逸分析是常见默认开启优化，可用 `-XX:-DoEscapeAnalysis` 做实验关闭
为什么线上不能依赖它	是否优化取决于热点程度、JIT、代码形态、内联、JDK 实现，语义上不能保证

本章小结

逃逸分析回答“对象引用会不会跑到外面去”。如果不会逃逸，JIT 可能做标量替换、分配消除和锁消除。所谓“对象不真正分配到堆上”，最准确的理解是：热点代码中某些对象可能被 JIT 优化到不再创建完整堆对象，而不是 Java 程序员可以手动控制对象放到栈上。

JDK 8/11/17/21 LTS演进

线程池

JIT 逃逸分析：对象为什么可能不真正分配到堆上 ​

学习目标 ​

为什么要有逃逸分析 ​

逃逸是什么意思 ​

不逃逸示例 ​

标量替换是什么 ​

方法逃逸示例 ​

线程逃逸示例 ​

锁消除是什么 ​

栈上分配到底怎么理解 ​

JIT 优化不是一开始就发生 ​

JDK 7、JDK 8 和后续版本 ​

Demo：对比逃逸分析开关 ​

什么写法更容易被优化 ​

商业项目中的理解方式 ​

常见误区 ​

和 OOM、GC 的关系 ​

面试标准回答 ​

追问回答 ​

本章小结 ​

JIT 逃逸分析：对象为什么可能不真正分配到堆上

学习目标

为什么要有逃逸分析

逃逸是什么意思

不逃逸示例

标量替换是什么

方法逃逸示例

线程逃逸示例

锁消除是什么

栈上分配到底怎么理解

JIT 优化不是一开始就发生

JDK 7、JDK 8 和后续版本

Demo：对比逃逸分析开关

什么写法更容易被优化

商业项目中的理解方式

常见误区

和 OOM、GC 的关系

面试标准回答

追问回答

本章小结