本文深入解析 ConcurrentModificationException 的真实成因，阐明其与多线程无关的本质，并通过对比传统索引循环与增强型 for 循环的底层机制，指导开发者在自定义数据结构（如哈希表）中安全遍历和修改 LinkedList 等集合。
本文深入解析 `concurrentmodificationexception` 的真实成因，阐明其与多线程无关的本质，并通过对比传统索引循环与增强型 for 循环的底层机制，指导开发者在自定义数据结构（如哈希表）中安全遍历和修改 `linkedlist` 等集合。
在实现自定义 MyHashMap 时，你可能遇到这样一个看似矛盾的现象：使用传统 for (int i = 0; i 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 方法中使用的索引循环：
for (int i = 0; i <p>⚠️ <strong>关键澄清</strong>：这段代码之所以不抛 ConcurrentModificationException，<strong>不是因为它“安全”，而是因为它根本没使用迭代器</strong>。它通过 get(i) 和 remove(Object) 手动访问元素，绕过了 Iterator 的校验逻辑。</p><p>但需警惕：此写法存在严重逻辑缺陷。list.remove(n) 是基于对象值的查找删除（时间复杂度 O(n)），且在 LinkedList 中会导致两次遍历（一次 get(i)，一次 remove(n) 内部查找）。更致命的是，若未及时 break，后续 i++ 会跳过下一个元素（因删除后索引前移），造成漏删。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill3430" title="Alibabacloud Sdk Client Initialization For Java"><img
src="https://img.php.cn/upload/skill/000/000/081/178955835420587.jpg" alt="Alibabacloud Sdk Client Initialization For Java" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill3430" title="Alibabacloud Sdk Client Initialization For Java" class="overflowclass">Alibabacloud Sdk Client Initialization For Java</a>
<p class="overflowclass">在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。</p>
</div>
<a rel="nofollow" href="/xiazai/skill3430" title="Alibabacloud Sdk Client Initialization For Java" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><h3>? 正确解法：使用 Iterator.remove()</h3><p>唯一被设计为<strong>遍历中安全删除</strong>的方式，是使用迭代器自身的 remove() 方法：</p><pre class="brush:php;toolbar:false;">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;
}
}
}</node></node>或者更简洁地使用增强型 for 循环 + 显式 Iterator（注意：不能在增强型 for 中直接调 list.remove()）：
Iterator<node> it = list.iterator();
while (it.hasNext()) {
Node n = it.next();
if (n.key == key) {
it.remove(); // 安全
return;
}
}</node>❌ 为什么 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 集合框架设计哲学的自定义数据结构。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
