编译优化：方法内联/锁消除/栈上分配

问题

JIT 编译之后，JVM 到底做了哪些优化让代码跑得更快？方法内联、锁消除、栈上分配这几个高频术语到底怎么工作的？什么时候生效、什么时候失效？

分析

方法论：JIT 的优化链条

JIT 编译优化不是独立的一步，而是一条流水线：字节码 → 中间表示（IR） → 逃逸分析 → 各种优化 → 机器码生成。三个优化项都依赖逃逸分析的结果，但各自解决的问题不同。

典型优化流水线时序：

字节码 → 解释执行（计数） → 达到 C1 阈值 → C1 编译（带简单优化）
         ↓ 计数继续累积
         达到 C2 阈值 → C2 编译（带深度优化：逃逸分析+内联+标量替换+锁消除）
         ↓
         替换栈上帧（On-Stack Replacement, OSR）

实战数据：某支付网关服务，核心转账链路 2000+ TPS，C2 编译后吞吐提升 40%，主要贡献来自方法内联（减少了 15% 的调用帧分配）和标量替换（减少了 8% 的 Young GC 次数）。

---

方法内联：消灭调用开销

为什么需要内联

方法调用虽然比十年前快，但依然有开销：参数传递、栈帧创建/销毁、跳转指令、返回指令。高频调用路径上，这些开销会累积到可感知的程度。

实测数据（JDK 17, C2 编译后）：

• 空方法调用 1 亿次，invokevirtual 开销约 12ms，内联后基本为 0
• 3 层嵌套调用链，内联后执行时间减少 35-45%
• 对于 10 字节以下的小方法，内联后吞吐提升可达 2x

方法内联（Method Inlining）直接把被调用方法的方法体复制到调用处，消除调用开销：

// 原始代码
int add(int a, int b) { return a + b; }

int result = add(3, 5);

// 内联后（JIT 视角）
int result = 3 + 5;

去虚化：内联的前提

对于接口方法调用，编译期无法确定具体实现类型，JIT 需要通过去虚化（Devirtualization）才能内联。

类型继承分析（CHA）：C2 遍历类加载历史，检查接口当前只有一个实现类 → 直接内联具体实现。如果后续加载了新的实现类，JIT 会废弃已编译代码，回退到解释执行再重新编译。

真实踩坑：某微服务引入 SPI 动态加载实现类，上线后接口性能骤降 30%。排查发现 SPI 加载时机在 C2 编译之后，新实现类加载导致 CHA 失效，已编译内联代码被废弃，回退到解释执行。解决方案：在预热阶段提前加载所有 SPI 实现类，或对接口加上 @ForceInline（JDK 9+）。

多态内联缓存（Polymorphic Inline Cache）：CHA 发现接口有多个实现时，C2 会生成一个内联缓存，记录 1-2 个最近遇到的实际类型，并附带条件判断。大部分情况下命中缓存，只有少数情况走完整虚方法分派。

典型场景对比：

场景	内联情况	性能影响
单实现接口	直接内联	最快，等同静态方法调用
2 个实现（90% 走 A）	多态内联缓存，命中 A	一次条件判断，接近直接内联
2 个实现（50% 走 A, 50% 走 B）	缓存频繁失效，走虚方法分派	性能下降 20-30%
4+ 个实现	无法内联，走 vtable 分派	最慢，但多数场景可接受

阈值参数

内联不是无条件的，JVM 有一整套参数控制：

参数	默认值	含义
-XX:MaxInlineSize	35 字节	方法体小于此值才内联（非热点）
-XX:FreqInlineSize	325 字节	热点方法体小于此值可内联
-XX:MaxInlineLevel	9 层	内联调用链的最大深度
-XX:MaxRecursiveInlineLevel	1 层	递归内联深度（递归调用基本不内联）
-XX:InlineSmallCode	2000 字节	内联后目标方法代码量上限

注意：MaxInlineSize 和 FreqInlineSize 是字节码长度，不是代码行数。一行 Java 代码可能编译成 5-15 字节字节码。一个 35 字节的方法，大概相当于 3-5 行代码。

观察内联决策

启动时加 -XX:+PrintInlining（JDK 9+ 用 -Xlog:inline=debug），输出类似：

@ 37   java.lang.String::charAt (5 bytes)   inline (hot)
@ 12   java.util.HashMap::get (112 bytes)   already compiled into a big method
@ 8    com.example.Service::process (45 bytes)   inline (hot)
@ 15   com.example.Service::doStuff (800 bytes)   too big

• inline (hot) 表示成功内联
• too big 表示超出大小阈值
• already compiled 表示目标方法已经编译过但未被内联
• callee is too large 同理

面试高频题：为什么 Spring 的 @Transactional 在同一个类中方法调用会失效？因为 this.method() 调用是 invokevirtual 非虚方法，AOP 代理无法拦截，事务注解不生效。C2 内联后直接把 method() 字节码嵌入调用处，更不可能走代理了。

不能内联的场景

• 虚方法多态：CHA 无法确定唯一类型
• 超大方法：超过 FreqInlineSize
• native 方法：没有字节码可以内联
• 递归调用：内联自己会无限展开
• 接口默认方法：JDK 8+ 接口 default 方法，CHA 无法确定具体实现类

---

锁消除与锁粗化：去掉不必要的同步

锁消除（Lock Elimination）

C2 通过逃逸分析发现 synchronized 块中的对象不会逃逸出当前线程，直接去掉锁操作。因为其他线程根本不可能访问到这个对象，加锁毫无意义。

经典案例：JDK 8 的 StringBuffer.append() 每个方法都是 synchronized 的：

public String toString() {
    StringBuilder sb = new StringBuilder();
    sb.append("a");  // 不逃逸 → 锁消除
    sb.append("b");  // 不逃逸 → 锁消除
    sb.append("c");  // 不逃逸 → 锁消除
    return sb.toString();
}

C2 通过逃逸分析发现 StringBuffer 对象只在方法内部使用，不会返回、不会赋值给成员变量、不会作为参数传给其他线程，因此所有锁操作被消除。单线程下 StringBuffer 和 StringBuilder 性能几乎一样，就是这个原因。

实测数据（1000 万次 append，JDK 17 C2 编译后）：

方案	耗时	GC 次数
StringBuilder（无锁）	45ms	0
StringBuffer（synchronized，C2 锁消除）	47ms	0
StringBuffer（关闭锁消除，-XX:-EliminateLocks）	380ms	12
手动 String 拼接	210ms	8

结论：C2 锁消除生效时，StringBuffer 和 StringBuilder 性能差异在 5% 以内，几乎可忽略。但关闭锁消除后，性能差 8 倍。

锁粗化（Lock Coarsening）

相邻代码块反复加锁/解锁同一对象，JVM 将锁范围合并：

// 原始代码导致多次加锁解锁
synchronized(lock) { count++; }
synchronized(lock) { flag = true; }
synchronized(lock) { notify(); }

// 锁粗化后等效于
synchronized(lock) {
    count++;
    flag = true;
    notify();
}

减少加解锁次数，减少上下文切换。但锁粗化只在相邻代码块之间做，不会跨方法调用合并。

锁粗化 vs 手动合并：锁粗化只对字节码层面相邻的 monitorenter/monitorexit 有效。如果代码块之间隔着方法调用，锁粗化不生效。不建议依赖锁粗化，写代码时该手动合并就手动合并。

面试常见陷阱

问：StringBuffer 线程安全，那多线程场景下用它是不是就安全了？

答：不是。StringBuffer 每个方法单独加锁，但多个方法调用的组合操作不是原子性的。例如：

StringBuffer sb = new StringBuffer();
// 线程 A：sb.append("a"); sb.append("b");
// 线程 B：sb.append("c"); sb.append("d");
// 结果可能是 "acbd" 或 "cadb"，不会出现数据损坏，但顺序不可预期

问：锁消除和偏向锁的区别？

特性	偏向锁	锁消除
作用阶段	运行时，偏向首次获取锁的线程	编译时，直接去掉锁操作
依赖	无竞争	逃逸分析判定对象不逃逸
效果	减少 CAS 操作	零开销
JDK 15+ 状态	已废弃（-XX:+UseBiasedLocking 默认关闭）	仍默认开启

---

栈上分配：让对象不进入堆

标量替换

栈上分配（Stack Allocation）通过标量替换（Scalar Replacement）实现——将对象拆散成独立的局部变量，分配在栈上或寄存器中：

// 原始代码
class Point {
    int x, y;
}
void draw() {
    Point p = new Point(10, 20);  // 堆分配
    // 使用 p.x, p.y
}

// 逃逸分析发现 p 不逃逸 → 标量替换为：
void draw() {
    int x = 10;  // 栈上或寄存器
    int y = 20;  // 栈上或寄存器
    // 使用 x, y
}

栈上分配的好处：

1. 零 GC 压力：方法返回时栈帧弹出，局部变量自动销毁，不需要 GC 回收
2. 更快的分配：栈分配只需移动栈指针，比堆分配（TLAB 分配也需要 CAS 操作）更快
3. 更好的缓存局部性：标量替换后的变量在栈上连续存放，CPU 缓存命中率高

什么情况下不生效

• 对象逃逸出方法（返回、赋值给成员变量、传入方法参数）
• 条件逃逸：JIT 无法确定是否逃逸时不会优化。例如：

void maybeEscape(boolean flag) {
    Point p = new Point();
    if (flag) {
        this.cache = p;  // 逃逸了！标量替换不生效
    }
    p.x = 1;  // 即使 flag 一般为 false，C2 仍保守处理
}

• 大对象：标量替换后栈帧放不下。实际 JVM 不实现真正的栈上分配，只做标量替换——把对象字段拆成独立变量。如果拆分后局部变量太多导致栈帧过大，C2 会放弃优化。
• 数组对象：标量替换对数组的支持有限，大部分情况数组仍走堆分配

// 数组的标量替换基本不生效
void allocArray() {
    int[] arr = new int[3];  // 即使不逃逸，也走堆分配
    arr[0] = 1;
    arr[1] = 2;
    arr[2] = 3;
}

验证栈上分配是否生效

使用 -XX:+PrintEscapeAnalysis 和 -XX:+EliminateAllocations（默认开启）查看逃逸分析结果。配合 -XX:+PrintGC 观察 GC 频率：

// 如果栈上分配生效，下面代码几乎不触发 GC
public class StackAllocTest {
    static class Point { int x, y; }

    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        long allocCount = 0;
        for (int i = 0; i < 500_000_000; i++) {
            alloc();  // 每次创建 Point 但不会导致频繁 GC
            allocCount++;
        }
        System.out.println("耗时: " + (System.currentTimeMillis() - start)
            + " ms, 分配次数: " + allocCount);
    }

    static void alloc() {
        Point p = new Point();  // 不逃逸 → 标量替换
        p.x = 1;
        p.y = 2;
    }
}

实测对比（JDK 17, 5 亿次调用）：

配置	耗时	GC 次数	GC 总停顿
默认（标量替换开启）	580ms	0-1	< 1ms
-XX:-EliminateAllocations	2850ms	47	320ms

关闭标量替换后，5 亿次堆分配直接撑爆 Young Gen，GC 频率飙升，执行时间接近 5 倍。

---

三种优化的关系

字节码
   ↓
逃逸分析（Escape Analysis）
   ├── 对象不逃逸 → 标量替换（栈上分配）
   ├── 对象不逃逸 → 锁消除（去掉 synchronized）
   └── 对象逃逸   → 不能优化
方法内联 ← 独立于逃逸分析，依赖 CHA 和调用计数

• 方法内联不需要逃逸分析，但需要去虚化
• 锁消除和栈上分配都依赖逃逸分析的结果
• 三种优化可以叠加：一个内联后的方法中，如果局部对象不逃逸，仍然可以栈上分配并锁消除

实战案例：某规则引擎的 eval() 方法，每次调用创建 10+ 临时对象（上下文、中间结果、对比值）。C2 编译后：

• 方法内联：将 eval() 内联到调用方，消除间接调用
• 标量替换：大部分临时对象被拆散成局部变量
• 结果：Young GC 频率从每秒 8 次降到 0.3 次，P99 延迟从 120ms 降到 18ms

---

总结

优化	解决的问题	依赖条件	关闭参数
方法内联	消除调用开销	方法体大小、热点度、CHA 去虚化	-XX:-Inline
锁消除	去掉不必要的同步	逃逸分析判定对象不逃逸	-XX:-EliminateLocks
锁粗化	合并相邻锁区间	同一对象多次加锁	无直接参数
栈上分配（标量替换）	对象不进入堆	逃逸分析判定对象不逃逸	-XX:-EliminateAllocations

生产建议：

• 不要为了让 JIT 能够优化而刻意写小方法——JIT 会自行判断
• 单线程场景下的 StringBuffer 和 StringBuilder 性能差异可忽略，C2 会消除锁；但不要依赖这个特性做多线程安全设计
• 排查性能问题时，先通过 -XX:+PrintInlining 确认内联情况，再深入分析逃逸分析
• JDK 17+ 的 ZGC 和逃逸分析兼容，不影响栈上分配
• 不要过度优化代码结构，JIT 的编译优化链已经很成熟，大部分「直觉优化」JIT 已经帮你做了
• 如果遇到「C2 编译后性能反而下降」的灵异现象，优先检查 CHA 失效（动态加载新类导致内联代码被废弃）和 PrintInlining 日志

面试追问：

• Q：为什么锁消除能消除 synchronized 但消除不了 Lock.lock()？
  A：Lock.lock() 是 Java 代码层显式调用，不是 JVM 字节码层面的 monitorenter，C2 不会对其做锁消除。LockSupport.park() 是 native 方法，同样无法优化。
• Q：StringBuilder 会被标量替换吗？
  A：StringBuilder 内部的 char[] 是数组，标量替换对数组支持有限，大部分情况 StringBuilder 对象仍走堆分配。但它的 append() 方法因为不涉及锁（不是 StringBuffer），所以影响不大。
• Q：-XX:-Inline 关闭内联会有什么后果？
  A：性能下降明显，但调试时非常有价值——可以排除内联对 Profiling 数据的干扰。线上生产环境绝对不要关闭。

参考资料：

• 《深入理解 Java 虚拟机》周志明（第 3 版）第 11 章
• OpenJDK HotSpot 源码：src/hotspot/share/opto/escape.hpp
• JVM 内联优化官方文档：https://wiki.openjdk.org/display/HotSpot/Inlining
• -XX:+PrintInlining 输出解读