在增强型 for 循环中如何正确安全遍历并修改 Java 集合

本文深入解析 ConcurrentModificationException 的真实成因，阐明其与多线程无关的本质，并通过对比传统索引循环与增强型 for 循环的底层机制，指导开发者在自定义数据结构（如哈希表）中安全遍历和修改 LinkedList 等集合。

本文深入解析 `concurrentmodificationexception` 的真实成因，阐明其与多线程无关的本质，并通过对比传统索引循环与增强型 for 循环的底层机制，指导开发者在自定义数据结构（如哈希表）中安全遍历和修改 `linkedlist` 等集合。

在实现自定义 MyHashMap 时，你可能遇到这样一个看似矛盾的现象：使用传统 for (int i = 0; i < list.size(); i++) 循环调用 list.remove(i) 能“成功运行”，而改用增强型 for 循环（即 for (Node n : list)）或显式 Iterator 进行遍历时，却立即抛出 java.util.ConcurrentModificationException。值得注意的是——该异常名称具有误导性：它并非仅在多线程并发场景下触发，而是在单线程中对集合进行结构性修改（如 add/remove）的同时，又通过迭代器（包括增强型 for 循环隐式创建的迭代器）继续遍历时必然发生的快速失败（fail-fast）机制。

? 根本原因：modCount 与 fail-fast 机制

Java 中的 LinkedList（及大多数 Collection 实现）维护一个名为 modCount（modification count）的内部计数器，用于记录集合结构被修改的次数。每当调用 add()、remove()、clear() 等结构性变更方法时，modCount 自增。而一旦创建 Iterator（增强型 for 循环底层即调用 list.iterator()），该迭代器会快照式记录当前 modCount 值为 expectedModCount。后续每次调用 iterator.next() 或 hasNext() 时，都会校验 modCount == expectedModCount；若不等（说明集合被外部修改过），立即抛出 ConcurrentModificationException。

例如，以下代码必抛异常：

for (Node n : list) {     // 创建 Iterator，记录初始 modCount    if (n.key == key) {        list.remove(n);   // 修改 list → modCount 变化 → 下次 next() 校验失败    }}

✅ 为什么传统索引循环“看似工作”？

你的 remove 方法中使用的索引循环：

立即学习“Java免费学习笔记（深入）”；

for (int i = 0; i < list.size(); i++) {    Node n = list.get(i);    if (n.key == key) {        list.remove(n); // 注意：此处 remove(Object) 是线性查找 + 删除，非按索引删除！        break;    }}

⚠️ 关键澄清：这段代码之所以不抛 ConcurrentModificationException，不是因为它“安全”，而是因为它根本没使用迭代器。它通过 get(i) 和 remove(Object) 手动访问元素，绕过了 Iterator 的校验逻辑。

但需警惕：此写法存在严重逻辑缺陷。list.remove(n) 是基于对象值的查找删除（时间复杂度 O(n)），且在 LinkedList 中会导致两次遍历（一次 get(i)，一次 remove(n) 内部查找）。更致命的是，若未及时 break，后续 i++ 会跳过下一个元素（因删除后索引前移），造成漏删。

? 正确解法：使用 Iterator.remove()

唯一被设计为遍历中安全删除的方式，是使用迭代器自身的 remove() 方法：

public void remove(int key) {    int index = key % MAX_VALUE;    LinkedList<Node> list = buckets[index];    if (list == null) return;    // 安全遍历并删除 —— 使用迭代器的 remove()    for (Iterator<Node> it = list.iterator(); it.hasNext(); ) {        Node n = it.next();        if (n.key == key) {            it.remove(); // ✅ 合法：迭代器知晓本次修改，同步更新 expectedModCount            return;        }    }}

或者更简洁地使用增强型 for 循环 + 显式 Iterator（注意：不能在增强型 for 中直接调 list.remove()）：

Iterator<Node> it = list.iterator();while (it.hasNext()) {    Node n = it.next();    if (n.key == key) {        it.remove(); // 安全        return;    }}

❌ 为什么 synchronized 无效？

你在注释中尝试加 synchronized(this)，但无效——因为 ConcurrentModificationException 是单线程内检测到结构不一致引发的，而非竞态条件（race condition）。加锁只能防止其他线程同时修改，但无法阻止同一个线程内“迭代器创建 → 集合被 list.remove() 修改 → 迭代器继续 next()”这一序列。modCount 校验发生在同一调用栈内，与线程同步无关。

✅ 最佳实践总结

场景	推荐方式	原因
遍历中需删除匹配元素	使用 Iterator.remove()	唯一被 Iterator 协议支持的安全删除方式
仅读取或无需删除	增强型 for 循环	简洁、可读性高
需按索引随机访问+修改	传统 for (int i=0; ...) + list.set(i, ...)	避免迭代器，但慎用 remove(i)（会改变后续索引）
多线程环境	配合 synchronized + Iterator.remove()，或改用 CopyOnWriteArrayList	兼顾线程安全与 fail-fast 语义

? 提示：在 MyHashMap.put() 中，if (get(key) != -1) remove(key); 存在性能隐患（先 get 再 remove 导致两次哈希桶遍历）。可优化为一次遍历完成查找与替换，进一步提升效率。

遵循上述原则，你不仅能彻底规避 ConcurrentModificationException，更能写出高效、健壮且符合 Java 集合框架设计哲学的自定义数据结构。