for循环仍是JVM上百万级数组纯遍历开销最小的方式；JIT对其优化成熟，而forEach和stream因对象分配、装箱拆箱等带来GC压力和延迟，且应缓存array.length以助向量化优化。
用 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 ，而非 <code>for (int i = 0; i - 如果数组长度在循环中可能被其他线程修改（极少见），则不能缓存——但此时你该考虑并发安全问题，而不是性能
- 注意：
arr.length是字段访问，不是方法调用，所以“反复读”成本低，但缓存后 JIT 更容易识别循环模式
遍历时慎用 System.out.println 或日志
百万次 println 不是慢在 Java 层，而是阻塞在系统 I/O 和缓冲区同步上。一次 println 平均耗时约 10–100μs（取决于终端/重定向目标），百万次就是几秒到几十秒，完全掩盖算法本身耗时。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 基准测试时务必关闭所有控制台输出，改用局部变量暂存结果（如
sum += arr[i]），最后一次性打印 - Log4j / SLF4J 的
debug()若未禁用，且配置了控制台 Appender，效果等同println - 用 JMH 做正式压测时，
@Fork和@Warmup可减少干扰，但输出本身仍是硬伤，必须剥离
确认你真在测「遍历」，而不是被 JIT 搞懵了
Java 的 JIT 编译器会在运行时把空循环或无副作用操作整个优化掉——比如只读数组、不做任何计算、也不保存结果，JIT 可能直接跳过整个循环体。这时你看到的“0ms”不是快，是没跑。
立即学习“Java免费学习笔记（深入）”；
- 确保循环体有可观察副作用：累加到
volatile变量、写入数组某位置、或返回一个计算结果并被后续使用 - 用 JMH 测试时，把结果赋给
@State对象的字段，并在@TearDown中引用它，防止被优化 - 简单验证法：在循环末尾加一句
System.nanoTime()赋值，再打印该值——只要这个值随数组大小变化，说明循环确实执行了
真正卡住性能的，往往不是“怎么写循环”，而是忘了关日志、信了被优化掉的毫秒数、或者误把 stream 当零成本抽象来用。
