为何两个独立循环比单个循环更快？Java循环优化探究

嘿，这个问题我太有共鸣了——之前做Java性能调优的时候，也曾对着循环融合的基准结果一脸困惑，咱们一步步拆解来看：

先确认你的核心预期是对的：JVM默认不会自动做循环融合 #

首先要拍板：HotSpot JVM（OpenJDK/Oracle JDK的核心）默认情况下不会自动执行循环融合优化。原因主要有两点：

• 循环融合的触发条件极其严苛：两个循环必须遍历完全相同的范围、无数据依赖（比如第一个循环的输出不是第二个循环的输入）、无任何副作用（比如循环内没调用非纯函数）。JVM的即时编译器（C2）不会冒风险自动做这个优化，除非你手动引导或开启特定实验性flag。
• 独立循环的缓存行为、指令并行特性反而可能被JVM做更针对性的优化，这也是你看到反直觉结果的关键。

为什么你的基准测试里独立循环反而更快？ #

这大概率和JMH的测试规范、缓存局部性、循环内操作的特性有关，常见的几个坑：

• JMH测试代码不规范：比如没避免死代码消除（循环操作的结果没被后续逻辑用到，JVM直接把整个循环删掉了）、热身/测量迭代次数不够、用了不合适的测试模式（比如Mode.SingleShotTime不适合循环类性能测试）。
• 缓存局部性的反向作用：如果两个独立循环操作的是不同的大数组，独立循环时CPU可以把第一个数组的缓存页完全加载后批量处理，再加载第二个数组的缓存页；而融合循环里每次都要交替访问两个数组的元素，若两个数组的内存布局刚好导致缓存频繁换入换出，命中率会大幅下降，反而变慢。
• JIT优化的差异：C2对独立循环可能做更充分的循环展开、向量化优化；而融合后的循环因为指令量增加，展开次数受限，指令级并行的效率反而降低。
• 循环内操作太简单：如果只是简单的数组赋值，JVM可能直接把循环完全优化掉，此时测试结果完全不反映真实的循环执行效率。

怎么正确验证循环融合的效果？ #

给你几个实操建议：

• 写规范的JMH基准代码：
  • 用@State注解保存循环操作的结果，避免JVM消除死代码；
  • 选择@BenchmarkMode(Mode.AverageTime)模式，设置足够的热身次数（比如@Warmup(iterations = 5)）和测量次数（@Measurement(iterations = 10)）；
  • 加上@Fork(1)避免进程间的JVM优化干扰。
• 查看JIT编译后的汇编代码：通过-XX:+PrintAssembly flag（需要提前安装hsdis工具），直接看C2对循环做了哪些优化——比如独立循环是不是被向量化了，融合循环有没有被特殊处理。
• 手动对比融合/独立循环的性能：把两个独立循环手动合并，再对比性能。如果手动融合后还是更慢，就重点分析缓存行为（比如用JOL工具查看数组的内存布局）。
• 尝试开启激进优化flag：虽然默认不支持，但可以试试-XX:+AggressiveOpts（注意新版本JDK可能移除或改名该flag），看看是否会触发循环融合。

举个典型的反例场景 #

比如你的测试代码可能是这样：

// 独立循环
for (int i = 0; i < size; i++) {
    arrayA[i] += 1;
}
for (int i = 0; i < size; i++) {
    arrayB[i] += 1;
}

// 融合后的循环
for (int i = 0; i < size; i++) {
    arrayA[i] += 1;
    arrayB[i] += 1;
}

如果arrayA和arrayB是两个超大数组，独立循环时CPU可以一次性加载arrayA的缓存页批量处理，再加载arrayB的缓存页；而融合循环里每次交替访问两个数组的元素，会导致缓存频繁失效，最终性能反而不如独立循环。

内容的提问来源于stack exchange，提问作者Francisco Ribeiro