Java遍历百万数组性能对比测试

在Java中对百万级数组进行纯遍历操作时，传统for循环凭借JIT成熟的优化能力，依然是性能最优的选择；而forEach和Stream因对象分配、装箱拆箱等开销会显著增加GC压力和延迟，甚至让遍历慢上数倍——真正影响性能的往往不是循环语法本身，而是被忽视的日志输出、未验证的JIT优化假象，以及误将函数式抽象当作零成本工具。掌握缓存array.length、禁用控制台输出、确保副作用不被JIT消除等实战细节，才能让基准测试反映真实性能，避免掉入“看似优雅、实则低效”的陷阱。

用 for 循环而不是 forEach 或 stream

对百万级数组做纯遍历（比如累加、查找、赋值），for 循环仍是 JVM 上最直接、开销最小的方式。JIT 编译器对传统 for 有成熟优化，而 forEach（需创建 Consumer 实例）和 stream（构建流水线、装箱/拆箱、额外对象分配）会带来明显 GC 压力和延迟。

• 避免写 Arrays.stream(arr).forEach(...) —— 即使是 int[]，也会触发自动装箱为 Integer，百万次就是百万个临时对象
• 别用 arr.forEach(...)（int[] 没这方法；Integer[] 有，但本质是增强 for，仍含迭代器开销）
• 若必须用函数式风格，至少用 IntStream.range(0, arr.length).forEach(i -> ...)，避免数据搬运，但依然比原生 for 慢 15%~30%

for 循环里别反复读取 array.length

JVM 虽然能对不变的 array.length 做基本的循环优化，但实际中仍建议显式缓存，尤其在 HotSpot 早期版本或非热点方法中。反复读取虽不报错，但可能阻止某些向量化优化（如自动向量化需要确定边界）。

• 写成 for (int i = 0, len = arr.length; i ，而非 for (int i = 0; i
• 如果数组长度在循环中可能被其他线程修改（极少见），则不能缓存——但此时你该考虑并发安全问题，而不是性能
• 注意：arr.length 是字段访问，不是方法调用，所以“反复读”成本低，但缓存后 JIT 更容易识别循环模式

遍历时慎用 System.out.println 或日志

百万次 println 不是慢在 Java 层，而是阻塞在系统 I/O 和缓冲区同步上。一次 println 平均耗时约 10–100μs（取决于终端/重定向目标），百万次就是几秒到几十秒，完全掩盖算法本身耗时。

• 基准测试时务必关闭所有控制台输出，改用局部变量暂存结果（如 sum += arr[i]），最后一次性打印
• Log4j / SLF4J 的 debug() 若未禁用，且配置了控制台 Appender，效果等同 println
• 用 JMH 做正式压测时，@Fork 和 @Warmup 可减少干扰，但输出本身仍是硬伤，必须剥离

确认你真在测「遍历」，而不是被 JIT 搞懵了

Java 的 JIT 编译器会在运行时把空循环或无副作用操作整个优化掉——比如只读数组、不做任何计算、也不保存结果，JIT 可能直接跳过整个循环体。这时你看到的“0ms”不是快，是没跑。

• 确保循环体有可观察副作用：累加到 volatile 变量、写入数组某位置、或返回一个计算结果并被后续使用
• 用 JMH 测试时，把结果赋给 @State 对象的字段，并在 @TearDown 中引用它，防止被优化
• 简单验证法：在循环末尾加一句 System.nanoTime() 赋值，再打印该值——只要这个值随数组大小变化，说明循环确实执行了

真正卡住性能的，往往不是“怎么写循环”，而是忘了关日志、信了被优化掉的毫秒数、或者误把 stream 当零成本抽象来用。

今天关于《Java遍历百万数组性能对比测试》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！