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,V> e : map.entrySet()) - 别写：
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 < 100; i++) { // 预热
for (int x : list) sum += x;
}
long start = System.nanoTime();
for (int i = 0; i < 1000; i++) {
sum = 0;
for (int x : list) sum += x; // 测试for-each
}
long time = System.nanoTime() - start;
注意：必须用sum参与计算，否则JIT可能把整个循环优化掉；每次测试前手动System.gc()不可靠，应确保堆足够大（-Xmx4g），让测试期间不触发GC。
最容易被忽略的是集合初始状态——ArrayList扩容、HashMap负载因子、TreeSet树高都会显著影响结果，测之前务必统一初始化参数。
