Java中传统for循环与增强for循环遍历一维数组性能基本一致，因JVM将其编译为几乎相同的字节码；真正影响性能的是循环体内操作、数据局部性及边界检查消除等因素。
在 Java 中遍历一维数组时，传统 for 循环（基于索引）和增强 for 循环（即 for-each）在绝大多数场景下性能差异极小，**JVM 会将二者编译为几乎相同的字节码**，实际运行效率基本一致。真正影响性能的，往往是循环体内的操作、数据局部性、是否发生边界检查消除等，而非循环语法本身。
字节码层面几乎等价
对一个 int[] arr 的遍历：
- 传统
for (int i = 0; i 编译后包含数组长度读取、索引比较、索引递增等指令； - 增强
for (int x : arr) { ... }在编译期被自动展开为相同逻辑：先读arr.length，再用索引逐个访问arr[i]，不使用迭代器（数组无 Iterator）。
现代 JDK（8u292+）中，JIT 编译器还能对两种写法都进行边界检查消除（BCE），进一步抹平差异。
关键差异其实在语义与灵活性
两者性能接近，但适用场景不同：
立即学习“Java免费学习笔记（深入）”；
- 需要索引（如修改元素、关联下标计算、双指针扫描）→ 必须用传统
for； - 只读访问且无需下标 → 增强
for更简洁、不易越界、可读性高； - 若循环中可能修改数组引用（如
arr = new int[...]），传统for中的arr.length会在每次迭代重读，而增强for在开始时就缓存长度——但这属于语义差异，不是性能优劣。
什么情况真会影响效率？
以下因素比“选哪种 for”更值得关注：
- 循环内有复杂对象创建或 I/O：比如每次迭代都 new 一个对象或调用 System.out.println()，这部分开销远超循环控制本身；
- 未启用 JIT 或代码未被热点编译：刚启动时解释执行，两种写法都慢，但差异仍不显著；
-
超大数组 + 非连续内存访问模式：比如跳着读（
i += 2）可能降低 CPU 缓存命中率，但这与 for 类型无关，而与访问模式有关。
建议：优先选可读性，而非微优化
除非经过 JMH 实际压测确认某处是瓶颈，且两种写法在该上下文中确实表现出统计显著差异（极少发生），否则：
- 读数组 → 用增强
for； - 需索引或修改原数组 → 用传统
for； - 避免为“看起来更快”而牺牲清晰性，比如强行把增强
for改成带索引的传统循环只为“省一次 length 调用”——JVM 早优化掉了。
不复杂但容易忽略：写出正确、易维护的代码，比在循环语法上节省纳秒级时间重要得多。
