1. 集合遍历的设计思路与选型考量1.1 为什么同一个需求会有这么多种写法先聊个普遍现象很多初学者学Java时最先接触的是for循环遍历List后来发现还有foreach、Iterator再后来碰到Stream流直接懵了——到底该学哪个用哪个面试官问什么其实这些遍历方式不是“哪个更好”的关系它们解决的是不同层面的问题。普通for循环靠下标访问foreach靠编译器帮你转成迭代器Iterator是集合框架底层的统一接口Stream则是Java 8引入的声明式遍历。它们之间的关系更像是“从面向过程到面向对象再到函数式”的演进而不是强势替代。这一点想清楚之后再看网上那些争论“for循环和foreach谁快”的帖子就不会被带偏了。快慢只是表象真正的核心在于你的遍历目的是什么集合本身支持什么以及你在遍历过程中需不需要做结构性修改。这三个问题确定了选型自然就出来了。1.2 遍历方式的选型地图我实战中会按照这张“决策清单”来选你可以直接抄作业需要下标、需要在遍历时修改当前元素的值直接用普通for循环。只读遍历不涉及删除优先foreach或增强for代码最简洁。遍历过程中需要删除元素使用Iterator并且调用它的remove方法或者用Java 8的removeIf。需要同时修改和读取且对遍历顺序有要求考虑ListIterator双向遍历。大数据集、无状态计算、多核环境下想榨干CPU性能用并行流但必须先做基准测试。遍历Map时entrySet()遍历效率最高keySet()再get()性能最差这是老生常谈但依然很多人踩坑。注意我在这里说的“迭代器”和“foreach”不是完全等同的。foreach在编译后被替换成基于迭代器的循环但它隐藏了迭代器对象你没法在循环体里直接调用iterator.remove()。所以面试题里常问“为什么foreach里不能添加或删除元素”本质就是在考Fail-Fast机制和迭代器内部状态的问题稍后我会详细讲。2. 传统for循环与foreach的底层逻辑2.1 普通for循环适合List不适合Set普通for循环通过get(int index)方法访问元素它的核心前提是集合必须支持“随机访问”。ArrayList实现了RandomAccess接口get操作的时间复杂度是O(1)所以用下标遍历非常快。但换成LinkedList虽然也可以用get(i)去遍历但每次get都是从头开始找整体复杂度变成O(n²)数据量一大直接卡死。// 正确示范ArrayList用for循环没问题 ListString list new ArrayList(); for (int i 0; i list.size(); i) { String item list.get(i); // 可以对item做处理 } // 反面教材LinkedList千万别这么写性能会断崖式下降 ListString linkedList new LinkedList(); for (int i 0; i linkedList.size(); i) { String item linkedList.get(i); // 每次get都从头部开始寻址 }这里还有个常见的性能陷阱循环条件里的size()方法。很多人写for (int i 0; i list.size(); i)实际上size()在ArrayList里只是返回成员变量没性能问题但业务代码里如果list是某个动态计算的结果每次都去重新计算集合大小就得不偿失了。普通for循环最大的优势还是能拿到下标这在需要记录位置、翻页、批量处理、比如每100条做一次批量插入这种场景没有下标就很蛋疼。2.2 foreach的本质语法糖背后的迭代器foreach其实是个语法糖。用javap反编译一下会发现编译后的字节码就是基于Iterator实现的while循环。它的好处是代码精简不需要手动维护下标且适用于所有实现了Iterable接口的集合Set、Queue、以及Map的entrySet、keySet、values等视图。// 这是你写的代码 for (String item : list) { System.out.println(item); } // 编译后大致等价于 IteratorString it list.iterator(); while (it.hasNext()) { String item it.next(); System.out.println(item); }这个“等价”背后藏着两件事hasNext()和next()的调用语义。hasNext()判断是否还有元素next()返回当前元素并移动游标。如果你在foreach循环体里修改了集合结构add或remove迭代器就会在下一次调用next()时抛出ConcurrentModificationException。原因简单说Iterator内部维护了一个expectedModCount每次next()都会验证集合的modCount是否和expectedModCount一致不一致就说明集合被改过了为了防止数据混乱直接快速失败。实操心得foreach里别用“先查后改”的逻辑。我见过不少人在foreach里先判断某个条件然后调list.remove(item)结果ConcurrentModificationException或者漏删数据。等下我会给出完整的删除方案。2.3 数组和集合的遍历方式差异数组在Java里本质是对象但它没有实现Iterable接口所以数组不能直接用foreach吗恰恰相反数组可以foreach但那是编译器对数组做的特殊处理用的是下标遍历不是迭代器。这个细节能区分基本原理到底扎不扎实String[] arr {a, b, c}; for (String s : arr) { // 这是编译器对数组的遍历优化不是通过Iterator }区别的意义在于数组的foreach没有fail-fast机制你在循环里修改数组的内容不一定会报错但这不代表是安全的。如果遍历的是集合你修改结构会快速失败如果遍历的是数组可能等数据写坏了你才反应过来。3. Iterator迭代器与Fail-Fast机制3.1 Iterator的工作原理和三个方法Iterator接口只有三个核心方法hasNext()、next()、remove()。经典用法是IteratorString iterator list.iterator(); while (iterator.hasNext()) { String item iterator.next(); if (item.startsWith(test)) { iterator.remove(); // 安全删除 } }remove()方法的官方语义是“移除next()方法返回的最后一个元素”。特别注意它只能跟在next()调用之后用并且在同一次next()之后只能调用一次remove()。如果你连着remove两次会抛出IllegalStateException。这个状态约束是很多新手写代码时完全没意识到的。机制层面Iterator接口隔离了遍历算法和集合的具体实现。对于使用者来说不管是ArrayList、HashSet还是TreeSet遍历方式都统一了。这也是为什么集合框架设计者强烈推荐用Iterator而不是写一堆针对具体类的遍历代码——面向接口编程在这里体现得很典型。3.2 Fail-Fast机制它到底在保护什么所谓Fail-Fast就是“快速失败”。当迭代器检测到集合在遍历过程中被结构性修改加、删元素而不是修改已有元素的值它会立刻抛异常而不是继续往下跑直到出错。ArrayList的Iterator里有个字段叫expectedModCount创建迭代器时它被初始化为当前集合的modCount。每次调用next()都会检查这个值有没有变化// ArrayList.Itr内部代码简化 int expectedModCount modCount; final void checkForComodification() { if (modCount ! expectedModCount) throw new ConcurrentModificationException(); }如果单线程下迭代器持有的expectedModCount和集合现在的modCount不一致立刻抛异常。这样设计的好处是避免“脏读”——你遍历到一半集合已经被改得面目全非继续读下去的结果谁也不敢保证正确性。注意ConcurrentModificationException并不代表Iterator在多线程下就完全不能用。它只能检测结构性修改无法保证数据同步。如果你真的需要在多线程环境下安全遍历应该用CopyOnWriteArrayList或ConcurrentHashMap这类并发容器它们的迭代器是弱一致性的不会抛CME但也不保证读到的数据是“最新”的。3.3 ListIterator能在遍历时修改的双向迭代器ListIterator是Iterator的子接口专门用于List集合它额外支持set()、add()、previous()、hasPrevious()等方法。典型场景是遍历过程中必须更新某个位置的元素值ListString list new ArrayList(Arrays.asList(a, b, c)); ListIteratorString listIterator list.listIterator(); while (listIterator.hasNext()) { String item listIterator.next(); if (b.equals(item)) { listIterator.set(B); // 替换当前元素 } } // 输出[a, B, c]注意set()和add()的区别set()是替换当前元素structural modification的计数器modCount不会增加所以不会触发ConcurrentModificationException而add()会改变集合大小modCount会增加在获取迭代器之后调用add()虽然它自身不会立刻抛异常但会影响后续迭代器的状态判断使用时要非常谨慎。4. 并行流与函数式遍历4.1 并行流的基本用法和原理Java 8引入Stream之后集合遍历又多了一种新姿势。普通stream是串行处理的parallelStream则会把任务拆分到多个线程上执行。用法很简单ListString list Arrays.asList(a, b, c, d); list.parallelStream() .map(String::toUpperCase) .forEach(System.out::println);但背后并不是“启动一堆线程无脑跑”而是基于ForkJoinPool的work-stealing机制把任务递归拆分成更小的子任务分配到不同线程上并行处理最后再合并结果。ForkJoinPool默认的并行度是CPU核心数减1Runtime.getRuntime().availableProcessors() - 1。forEach的并行版本在做多线程输出时执行顺序是不确定的。如果你期望“处理完a再处理b”用parallelStream的forEach一定会翻车。如果既要并行能力又要保持顺序用forEachOrdered// 保持并行处理能力但输出顺序与源集合一致 list.parallelStream() .map(...) .forEachOrdered(System.out::println);forEachOrdered在并行流下会牺牲一定的并行度因为它在收集结果时做了排序。所以需要自己权衡如果只是做聚合统计比如求和、过滤、找最大值无所谓顺序直接forEach如果每条结果必须按源集合的顺序写文件、插数据库要么用forEachOrdered要么收集完再排序。4.2 并行流的性能真相和三个适用前提并行流不是银弹甚至很多时候比串行还慢。我总结过三个必须同时满足的前提缺一个都不建议上parallelStream数据量足够大。几万条以下的小集合线程池的创建、任务拆分和结果合并的开销远大于计算本身实测ArrayList 算一万个数求和并行流甚至不如普通stream。元素数据处理无状态、无顺序依赖。每一个元素的处理不依赖其他元素比如map、filter这类操作天然适合并行但reduce、collect之类的操作如果涉及共享状态或外部IO要格外当心。单核资源没有完全饱和。如果机器本身CPU已经跑满并行流只是让线程疯狂切换反而拖慢整体吞吐。我见过一个真实案例服务器8核内存充足一个批处理任务把一堆订单JSON转成DTO对象再落库直接用parallelStream结果数据库连接池被打爆最后加了信号量控制并发数才稳定下来。后来改成线程池加串行流反而更可控。4.3 并行流的线程池陷阱这也是面试高频题parallelStream用的默认ForkJoinPool是公共的所有parallelStream调用共享同一个池。如果某个任务在池里发生了阻塞比如socket等待、数据库等待它会占用公共池的线程影响其他所有并行流任务。所以如果要做真正的并行批量处理我建议自己创建专有的ForkJoinPool或者ThreadPoolExecutor把parallelStream包进去不要用默认池。不过Java原生的parallelStream不能在调用的地方直接指定线程池需要通过偷换“宿主线程”的方式实操比较绕。更优雅的做法是直接不用parallelStream改用CompletableFuture或者外部线程池配合普通stream。5. 集合遍历中的常见问题排查与速查表5.1 高频异常和它们的真实原因ConcurrentModificationException是最典型的遍历问题原因分三类foreach或Iterator遍历时在循环体内调用list.add()/list.remove()。多线程环境下一个线程遍历、另一个线程修改同一个集合。使用子列表subList时原列表发生了结构性修改再去操作子列表也会撞上modCount校验。排查经验异常堆栈里会明确指出抛错的位置先看堆栈里的next()或checkForComodification()再看是哪一行代码调用了add或remove。如果是多线程别急着贴锁先确认业务上是否真的需要并发修改很多时候把集合换成CopyOnWriteArrayList或ConcurrentHashMap就解决了。IllegalStateException出现在Iterator调用remove()后没有先调用next()或连续调用两次remove()。这属于使用姿势问题调整判断逻辑就能避开。IndexOutOfBoundsException在for循环删除元素时最容易遇到经典的“倒着删”或“remove后i回退”都是这个场景。老老实实用迭代器的remove或者直接removeIf。5.2 遍历中删除元素的四种姿势我整理了从“能用但很丑”到“优雅且安全”的完整方案方式代码示例是否线程安全适用场景倒序for removefor (int i size-1; i 0; i--) { list.remove(i); }否简单场景、ArrayList、删除后不需要保留顺序Iterator removeIterator it list.iterator(); while(it.hasNext()){ it.next(); it.remove(); }否任意Collection、需要遍历时删除removeIflist.removeIf(item - conditionMatch(item));否Java 8、删除逻辑简单收集-再删除List toRemove list.stream().filter(...).collect(toList()); list.removeAll(toRemove);否待删除元素需要先综合分析或需要做二次确认实操心得从Java 8开始如果只是删元素removeIf是最省事的。它的底层其实是迭代器遍历加remove但你不用手动写循环。但注意removeIf传的是Predicate别把需要处理业务逻辑的内容塞进去否则可读性会很差。多线程环境下要删元素优先CopyOnWriteArrayList的removeIf或者用Collections.synchronizedList加锁包一层但加锁时要连遍历一起锁住否则遍历过程中其他线程修改了结构同样会带来隐患。5.3 遍历性能对比的实测参考我做过一个简单基准测试10万条整型数据的ArrayList分别用几个方式累计求和单位毫秒环境是JDK 178核机器遍历方式耗时约说明普通for4-6O(1)随机访问foreach4-6编译成迭代器但ArrayList的迭代器做了额外边界检查Iterator显式遍历4-7与foreach几乎一致Stream串行5-8有轻微装箱和流对象开销Stream并行2-3数据量够大时效果明显Stream并行数据量1k20小数据集开销反而更大注意这些数字会随着JDK版本、集合大小、业务复杂度变化别直接背结论。我建议每个项目里真的遇到性能瓶颈时用JMH写个微基准再做决定别靠感觉优化。一个重要提醒性能不是遍历方式选择的首要因素。代码可读性、维护成本、是否会引发并发问题这些远比那几毫秒重要。一个清晰直观的foreach远胜过一个再精妙但让人满头雾水的手动迭代器循环。5.4 遍历循环中修改元素值的安全姿势如果只是把集合里的值做更新不需要增删元素且用的是List那最简单的是普通for循环配合set方法for (int i 0; i list.size(); i) { String s list.get(i); if (s ! null) { list.set(i, s.trim()); } }如果是Map要修改value只能遍历entrySet然后调用setValue或者遍历keySet再put这不算结构性修改因为Map的put更新已有key不会改modCountMapString, String map new HashMap(); for (Map.EntryString, String entry : map.entrySet()) { if (entry.getValue() null) { entry.setValue(N/A); } }注意HashMap的KeySet、entrySet遍历时如果put进去一个原来不存在的key那就是结构性修改会触发CME。更新已有key则不会。这个边界很多熟练工都搞混过。最后的实践经验做Java这些年集合遍历这个题目看着简单但它像一个十字路口把数据结构基础、接口设计、并发模型、性能意识全串起来了。面试和日常开发中我建议你把“遍历”当成一个完整的思维模型去理解而不是背语法先想清楚集合底层结构数组也好、链表也好、哈希表也好再想你的操作是否涉及结构性修改最后想想有没有并发场景。这三个问题想透了用什么写法基本是顺理成章的事。如果只让我留一句经验那就是能用foreach表达意图的就别写for循环需要删除元素时优先removeIf而不是手动维护下标数据量大且无状态计算才考虑parallelStream并且无论如何先跑一次基准测试。这套组合拳能帮你避掉绝大多数遍历相关的坑。
