CPU Cache场景下C++与Java数组遍历性能差异原因求解

你观察到的差异主要来自三个核心原因：

• 数组初始化与缺页中断的开销差异
  Java的new int[]在分配内存时会同步完成所有元素的零值初始化，这个过程已经触发了全部内存页的分配、映射，同时完成了TLB（页表缓存）的预热。你代码中第一个测试循环运行时，已经没有缺页中断开销，所有内存页都处于可直接访问的状态。
  而C代码中定义的是全局大数组int a[N]，这类静态存储区的大数组默认采用懒加载机制：操作系统只会在程序第一次访问对应内存页时才分配物理内存、完成地址映射。第一个步长为1的循环要遍历整个512MB数组，会触发超过13万次缺页中断（按4KB页计算），这部分开销直接拉高了第一个循环的耗时。第二个步长为16的循环运行时，所有内存页已经完成映射，无需承担缺页开销。
  你可以尝试把C代码中的两个循环调换执行顺序，或者在进入测试循环前先遍历一次整个数组完成预热，就能明显缩小两者的耗时差。
• 编译优化策略的差异
  Java的Server模式JIT会对大数组连续写入的场景自动生成非临时存储（Non-Temporal Store）指令，这类指令可以绕过CPU缓存直接写入内存，避免了512MB数据全部灌入缓存导致的频繁缓存淘汰开销，同时利用写入合并（Write Combining）机制大幅提升连续写入的带宽。
  而你用默认参数编译的g++（或macOS下实际为clang别名的g++）不会默认生成非临时存储指令，步长为1的循环写入的512MB数据会全部经过CPU缓存，大量的缓存换入换出操作带来了额外开销。步长为16的循环仅写入1/16的数据，缓存占用低，开销自然更小。你可以给g++加上-march=native参数启用CPU特性优化，也能缩小两者的耗时差。
• 循环开销的占比差异
  你提到的缓存行原理本身是成立的：步长1和步长16的循环都只需要每个缓存行触发一次内存写入操作。当没有缺页、缓存污染这些额外开销时，循环内部的自增、赋值操作的占比极低，两者耗时自然接近，就是你在Java中看到的结果。当C++的第一个循环叠加了缺页、缓存污染的额外开销后，耗时就会明显高于没有这些开销的步长16循环。

内容的提问来源于stack exchange，提问作者Lixin Wei