iterator遍历不一定比for循环慢，性能取决于集合类型和jvm优化：arraylist上for快10%~20%，linkedlist上iterator更优；hashmap遍历时entryset()比keyset()+get()快2.3倍；stream.foreach()纯遍历更慢，仅适合链式操作或并行。

Iterator遍历比for循环慢吗？看集合类型和JVM优化

不是绝对慢，而是取决于底层数据结构和JVM是否能内联/消除迭代器开销。ArrayList上for循环通常快10%~20%，LinkedList上Iterator反而更稳——因为get(i)在链表里是O(n)操作，而Iterator.next()是O(1)。

关键点在于：JIT编译后，ArrayList.iterator()生成的Itr对象可能被逃逸分析优化掉，但前提是循环体足够简单、没逃逸引用。

• 测试前关掉预热干扰：-XX:-TieredStopAtLevel + 至少5轮预热
• 用JMH跑，别手写System.nanoTime()——后者容易被JIT优化成空循环
• 避免在循环里调用toString()或打印日志，这会掩盖真实遍历开销

HashMap遍历时用entrySet()还是keySet() + get()？

keySet() + get()在大多数场景下是隐形性能杀手：每次get()都要重新哈希、寻址、处理冲突。而entrySet().iterator()直接遍历桶数组+链表/红黑树节点，一次定位就拿到key和value。

实测（JDK 17，10万Entry）：entrySet()遍历比keySet()+get()快2.3倍左右；用forEach() lambda反而略慢——因为创建了Consumer实例，且无法被完全内联。

• 优先写：map.entrySet().iterator() 或 for (Map.Entry<k> e : map.entrySet())</k>
• 别写：for (K k : map.keySet()) { V v = map.get(k); ... }
• 注意：ConcurrentHashMap的entrySet()是弱一致视图，不保证反映最新修改

Stream.forEach()和传统for谁更快？别无脑转Stream

单纯遍历+简单操作时，Stream.forEach()几乎总是更慢：它要构造ReferencePipeline、触发terminalOp、多一层函数式抽象，还常触发额外的装箱/拆箱。

只有当你需要链式操作（filter/map/reduce）或并行化（parallelStream()）时，Stream才有意义。单线程纯遍历，for或Iterator更直接。

• 反模式：list.stream().forEach(System.out::println) → 直接for或list.forEach()（后者是Iterable默认方法，无Stream开销）
• 真正适合Stream的场景：需要中间操作，比如list.stream().filter(...).map(...).collect(Collectors.toList())
• list.forEach()（接口默认方法）≈ 手写for循环，但不能break或continue

怎么实测？避开JIT和GC干扰的最小可行方案

用JMH最稳妥，但如果只是快速验证，可以这样压测：

// 关键：让JIT认为这是“热路径”，且避免GC打断
List<integer> list = IntStream.range(0, 1_000_000).boxed().collect(Collectors.toList());
long sum = 0;
for (int i = 0; i <p>注意：必须用<code>sum</code>参与计算，否则JIT可能把整个循环优化掉；每次测试前手动<code>System.gc()</code>不可靠，应确保堆足够大（<code>-Xmx4g</code>），让测试期间不触发GC。</p>
<p>最容易被忽略的是集合初始状态——<code>ArrayList</code>扩容、<code>HashMap</code>负载因子、<code>TreeSet</code>树高都会显著影响结果，测之前务必统一初始化参数。</p></integer>