JIT 优化技术：方法内联、标量替换、锁消除、公共子表达式消除（069）

知识库文档 70 / 251

一、JIT 优化不是魔法，是一系列可拆解的编译技术

上一篇文章（068）讲了 JIT 编译的整体流程——分层编译、热点探测、去优化。本文深入到 C2 编译器内部，逐一拆解四种最核心的优化技术。理解了这些技术的原理和限制，你就能写出"对 JIT 友好"的代码，而不是靠运气指望 JIT 帮你优化。

四种技术的优先级排序：

方法内联（Method Inlining）：JIT 优化的基石，几乎所有其他优化都依赖内联。
标量替换（Scalar Replacement）：消除对象分配，内联之后才能做。
锁消除（Lock Elision）：消除不必要的同步，同样是内联之后才能做。
公共子表达式消除（CSE）：消除重复计算，JIT 中最基础的优化。

二、方法内联：JIT 优化的基石

方法内联是 C2 编译器中最重要、影响最大的单项优化。它本身不直接提升性能，但它为其他所有优化打开了大门：

内联后，被调用方法的代码变成调用者的一部分，消除了方法调用的开销。
内联后，C2 可以看到更大的代码上下文，做跨方法的优化。
内联后，逃逸分析才能分析被调用方法中创建的对象。
内联后，锁消除才能消除被调用方法中的 synchronized。
内联后，虚方法调用可以转化为直接调用，甚至完全消除。

可以说，没有内联，C2 的优化能力会大打折扣。

C2 决定是否内联主要考虑：被内联方法的热字节码大小不能超过 FreqInlineSize（默认 325 字节）、调用深度限制（MaxInlineLevel 默认 9）、虚方法调用的实际接收者是否单一（单态内联）。

虚方法调用的单态内联示例：

java

// 原始代码
public void process(Animal animal) {
    animal.speak(); // 虚方法调用
}

// 单态内联后（等价于）
public void process(Animal animal) {
    if (animal.getClass() == Dog.class) {
        // Dog.speak() 的代码被内联到这里
        System.out.println("Woof!");
    } else {
        animal.speak(); // 走回虚方法调用
    }
}

内联失效的常见场景：方法太大（超过阈值）、虚方法接收者过多（超过 TypeProfileWidth 默认 2）、递归调用、synchronized 方法。

查看内联决策：-XX:+PrintInlining。输出中 too big 表示无法内联，hot 表示内联成功，not hot 表示 profiling 数据不足。

[图1：方法内联示意图——左侧内联前A→B→C有栈帧开销，右侧内联后A内含B和C代码]

三、标量替换：消除对象分配

当一个对象被逃逸分析判定为"不逃逸"时，C2 可以将这个对象的成员变量拆开为独立的局部变量，不再需要在堆上分配对象本身。

java

// 原始代码
public int distance() {
    Point p = new Point(3, 4);
    return p.x * p.x + p.y * p.y;
}

// 标量替换后
public int distance() {
    int p_x = 3; int p_y = 4;
    return p_x * p_x + p_y * p_y;
}
// Point 对象完全被消除，不需要在堆上分配，不需要 GC

标量替换的收益：零分配（不消耗堆内存）、缓存友好（标量在寄存器或栈上）、无 GC 压力。一个热点方法如果每秒创建 100 万个 Point 对象，标量替换后这 100 万个对象完全消失。

标量替换失效场景：对象被返回给调用者、被赋值给数组/集合元素、被传递给未内联的方法、对象包含超过 64 个字段。

[图2：标量替换示意图——左侧Point对象堆分配，右侧x和y拆分为独立局部变量，零堆分配]

四、锁消除：去掉不必要的同步

如果逃逸分析判定一个对象不会被多个线程访问，那么对该对象的 synchronized 操作是多余的。C2 可以直接消除这些 synchronized 块。

java

// 原始代码
public String concat(String a, String b) {
    StringBuffer sb = new StringBuffer();  // 不会逃逸
    sb.append(a); sb.append(b);
    return sb.toString();
}

// 锁消除后（等价于）
public String concat(String a, String b) {
    StringBuilder sb = new StringBuilder();  // 非同步版本
    sb.append(a); sb.append(b);
    return sb.toString();
}

锁消除对性能的提升远超直觉——即使没有竞争，synchronized 的获取和释放也有开销。消除一个热点路径上的锁，可以带来 10-50% 的性能提升。局限：锁消除只支持 synchronized，不支持 java.util.concurrent.locks.Lock。

[图3：锁消除示意图——左侧StringBuffer同步append，右侧等价StringBuilder无同步]

五、公共子表达式消除（CSE）

如果一段代码中多次计算了相同的表达式，且两次计算之间输入值没有变化，C2 可以将第一次计算的结果保存下来，后续直接复用。

java

// 原始代码
int x = a * b + c; int y = a * b + d; int z = a * b + e;

// CSE 优化后
int temp = a * b;  // 只计算一次
int x = temp + c; int y = temp + d; int z = temp + e;

数组边界检查消除是 CSE 的一种特殊形式——如果循环中多次访问同一个数组索引，C2 可以消除重复的边界检查。CSE 只对"纯计算"有效，如果表达式有副作用（方法调用、字段写入），C2 不能随意消除。

[图4：JIT优化技术全景层次图——从方法内联→逃逸分析→标量替换/锁消除/CSE→循环展开]

六、其他值得了解的 JIT 优化

循环展开（Loop Unrolling）：将循环体复制多次，减少循环条件判断和跳转的次数。
死代码消除（Dead Code Elimination）：删除永远不会执行到或结果永远不会被使用的代码。
分支预测优化：C2 根据 profiling 数据将高频分支放在"热路径"上，低频分支放在"冷路径"上。
空值检查消除：如果 profiling 数据显示某个参数从未为 null，C2 可以消除空值检查。

七、优化技术的协同效应

JIT 优化不是孤立的，它们之间存在强烈的协同依赖：

方法内联（基础）-> 扩大编译视野 -> 逃逸分析（依赖内联后的大代码上下文）-> 标量替换（依赖逃逸分析）+ 锁消除（依赖逃逸分析）。CSE 在内联后更多表达式暴露，效果更好。循环展开在内联后循环体更大，展开收益更高。

理解这个依赖链，你就能理解为什么方法内联是最重要的 JIT 优化。一个方法如果无法被内联，后续的逃逸分析、标量替换、锁消除全部失效。

[图5：JIT优化依赖链树状图——方法内联→逃逸分析→标量替换/锁消除，标注前提和失效场景]

八、写出对 JIT 友好的代码

方法内联：保持方法体短小（< 325 字节字节码），避免在热点路径上使用过多的虚方法调用，考虑使用 final 方法或 static 方法。

标量替换：对象在方法内部创建、使用、销毁，不要返回给调用者，不要将局部对象放入集合或数组。

锁消除：使用局部变量存储锁对象，优先使用 StringBuilder 而非 StringBuffer。

CSE：避免在表达式中调用有副作用的方法，将重复计算提取为局部变量。

[图6：对JIT友好的代码编写四象限指南——DO/DON'T对照，绿/红色标注]

九、面试常见误区

"JIT 会自动优化，不用关心代码怎么写" —— 错误。JIT 的优化能力受限于内联阈值和逃逸分析边界，不友好的代码会让 JIT 有力使不出。
"synchronized 性能差，尽量不用" —— 不准确。在无竞争场景下开销很低，JIT 的锁消除可以完全消除局部对象的同步开销。
"final 方法没有性能优势" —— 对 C2 来说，final 方法可以直接内联，省去了虚方法调用的 profiling 和类型检查开销。
"对象分配很便宜，不用关心" —— 分配确实便宜，但对象多了会导致 GC 压力。标量替换可以让你同时享受对象封装的代码清晰性和零分配优势。

十、总结

JIT 优化技术的核心是"内联驱动一切"：

方法内联：JIT 优化的基石，为其他优化打开大门。
标量替换：消除对象分配，内联 + 逃逸分析之后才能做。
锁消除：消除不必要的同步，同样依赖内联 + 逃逸分析。
公共子表达式消除：消除重复计算，基础但有价值的优化。

写出对 JIT 友好的代码，不是死记参数，而是理解这些优化的前提条件——方法要短小才能内联，对象要局部才能消除，锁要局部才能消除。这些原则和良好的代码设计天然一致。

面试官视角：提问与回答

以下问题从面试官视角出发，考察你对 JIT 优化技术的深度理解和实战应用。

Q1：你在 PrintInlining 日志中看到一个热点方法被标记为 "too big" 无法内联，但这个方法只有 400 字节的字节码。你会怎么优化？

400 字节超过 FreqInlineSize（默认 325 字节），确实无法内联。优化方案：1）将大方法拆分为多个小方法，每个方法 < 325 字节字节码，C2 可以分别内联。2）如果拆分后某个方法确实无法再缩小，可以用 @ForceInline（JDK 内部 API）强制内联，但要注意这可能导致编译后的代码膨胀。3）检查方法中是否有可以提取为独立方法的重复逻辑块，拆分后不仅有利于内联，也提高了代码可读性。4）如果方法中有大量字符串拼接，考虑用 StringBuilder 替代 + 操作符，减少字节码大小。5）检查是否有不必要的异常处理块——每个 catch 块都会增加字节码大小，精简异常处理逻辑。

Q2：标量替换消除了对象分配，但你在代码中使用了逃逸分析无法优化的模式（比如将局部对象放入 ArrayList 再遍历）。这种情况下，你怎么在"代码可读性"和"JIT 优化友好"之间做权衡？

这是一个典型的"代码设计 vs 性能优化"的权衡。我的原则是：1）先保证代码可读性和正确性，不要过早优化。2）在热点路径上（通过 profiling 确认），才考虑为 JIT 优化做代码调整。3）对于 ArrayList 的场景，如果集合大小固定且很小，可以手动展开循环：Item a = list.get(0); Item b = list.get(1); process(a); process(b); 这样每个 Item 对象都可以被标量替换。4）如果集合大小不固定，考虑用数组 + 循环代替 ArrayList——数组的边界检查可以被 C2 消除，而 ArrayList 的方法调用（get/set）可能阻碍内联。5）终极方案：如果热点路径的分配压力确实大，用 JMH 测试有/无优化的性能差异，用数据说话，而不是凭直觉。如果差异 < 5%，保留可读性高的代码。

Q3：锁消除只对 synchronized 生效，对 ReentrantLock 不生效。你在一个高并发场景下，局部使用了 ReentrantLock，JIT 无法消除。你会怎么优化？

如果确认锁对象是局部的（不会逃逸出当前线程），我会直接将 ReentrantLock 替换为 synchronized——C2 可以消除 synchronized。虽然很多人认为 ReentrantLock 性能更好，但这是针对有竞争的场景。在无竞争且对象局部的场景下，synchronized + JIT 锁消除的性能远优于 ReentrantLock（因为 ReentrantLock 即使无竞争也需要 CAS 操作，而锁消除后 synchronized 完全没有开销）。如果由于 API 兼容性不能替换为 synchronized，可以考虑将锁操作移到调用方——在调用方确保单线程访问，被调用方不需要任何锁。如果以上都不行，接受这个开销，用 JMH 确认实际影响，如果影响小就不优化。

Q4：你在代码中看到一个方法，它先创建一个 StringBuilder，append 了 10 个字符串，然后调用 toString() 返回。这个方法会被 JIT 做标量替换吗？为什么？

不会做完全的标量替换。StringBuilder 对象本身可能被标量替换（如果它没有被传递给未内联的方法），但它内部持有的 char 数组也会随着 toString() 返回的 String 逃逸。所以这个方法中，JIT 能做的优化有限：StringBuilder 对象本身可能被标量替换，但最终的 String 对象和其内部的 char 数组仍然需要在堆上分配。如果想优化，可以用 String.format 或者直接拼接字符串常量（如果内容在编译期已知），或者让调用者传入一个 StringBuilder 来复用，或者用 JDK 9+ 的 StringConcatFactory（invokedynamic 的字符串拼接）让 JIT 做更智能的优化。

Q5：C2 的公共子表达式消除（CSE）和开发者在代码中手动提取公共表达式，哪个更好？为什么有些场景下 C2 的 CSE 反而不如手动提取？

C2 的 CSE 在大多数情况下和手动提取效果相同，但有以下场景 C2 做不了而手动提取可以：1）跨方法边界——C2 只能在内联后才能做跨方法的 CSE，如果方法没有内联，CSE 无法跨方法生效。手动提取在源码层面就完成了。2）副作用判断——C2 需要保守地判断表达式是否有副作用，如果表达式中有方法调用（即使是纯方法），C2 可能不敢消除。手动提取表明开发者知道这个方法没有副作用。3）volatile 字段——C2 对 volatile 字段的读取非常保守，不会跨 volatile 读取做 CSE，因为 volatile 值可能被其他线程修改。手动提取可以表示"我知道这里 volatile 不会变"。4）可读性——手动提取的公共表达式给变量一个有意义的名字，帮助代码维护。总的来说：在热点路径上，手动提取 > 依赖 C2；在非热点路径上，依赖 C2 即可，保持代码简洁。

JIT 优化技术：方法内联、标量替换、锁消除、公共子表达式消除（069）

一、JIT 优化不是魔法，是一系列可拆解的编译技术

二、方法内联：JIT 优化的基石

三、标量替换：消除对象分配

四、锁消除：去掉不必要的同步

五、公共子表达式消除（CSE）

六、其他值得了解的 JIT 优化

七、优化技术的协同效应

八、写出对 JIT 友好的代码

九、面试常见误区

十、总结

延伸阅读

面试官视角：提问与回答