详解集合的fail-fast与fail-safe机制_并发修改异常的触发与规避

“纵有疾风来，人生不言弃”，这句话送给正在学习文章的朋友们，也希望在阅读本文《详解集合的fail-fast与fail-safe机制_并发修改异常的触发与规避》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新文章相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

ArrayList遍历时调用remove()抛ConcurrentModificationException，因fail-fast机制通过modCount与expectedModCount比对检测结构修改；安全做法是用Iterator.remove()或removeAll()。

为什么遍历 ArrayList 时调用 remove() 会抛 ConcurrentModificationException

这是典型的 fail-fast 行为：集合在迭代过程中检测到结构被意外修改（比如非迭代器自身的 remove()），就立即报错。底层靠一个叫 modCount 的修改计数器和迭代器持有的 expectedModCount 做比对，不一致就炸。

常见错误现象：

• 用普通 for 循环边遍历边 list.remove(obj) —— 炸
• 用增强 for（for (X x : list)）调 list.remove() —— 炸
• 多线程里一个线程迭代、另一个线程增删 —— 大概率炸

实操建议：

• 单线程下安全删除：用迭代器的 iterator.remove()，它会同步更新 expectedModCount
• 需要按条件批量删：先收集待删元素，再用 list.removeAll(toRemove)
• 别依赖“偶尔不炸”——modCount 检查不是每次都触发（比如删的是最后一个元素可能侥幸逃过），但行为不可靠

CopyOnWriteArrayList 真的线程安全？它怎么做到不抛异常

它实现的是 fail-safe：迭代器基于创建时刻的数组快照工作，后续所有写操作（add/remove）都新建数组、复制旧数据，原迭代器继续读老数组，自然不会冲突。

使用场景：

• 读远多于写的并发场景（如监听器列表、配置白名单）
• 需要遍历时允许写，且能接受“读不到最新写入”的语义

性能与兼容性注意点：

• 每次写都复制整个数组 → 写操作开销大，大数据量慎用
• 迭代器无法反映迭代期间的变更 → 如果业务逻辑依赖“实时一致性”，它反而会出问题
• 不支持 Iterator.remove()（抛 UnsupportedOperationException），因为快照不可变

示例：

CopyOnWriteArrayList list = new CopyOnWriteArrayList();
list.add("a");
Iterator it = list.iterator();
list.add("b"); // 迭代器 still sees only ["a"]
while (it.hasNext()) System.out.println(it.next()); // 只输出 a

HashMap 的 entrySet().iterator() 也会 fail-fast 吗

会。和 ArrayList 一样，HashMap 的迭代器也检查 modCount。只要在迭代 entrySet、keySet 或 values 时，用 map.put()、map.remove() 改了结构，就抛 ConcurrentModificationException。

容易踩的坑：

• 用增强 for 遍历 map.entrySet()，然后在循环体里调 map.remove(key) —— 炸
• 认为“只读 key 或 value 就安全”——错，keySet() 和 values() 的迭代器同样受 modCount 约束

实操建议：

• 要边遍历边删键值对：用 Iterator> it = map.entrySet().iterator()，然后调 it.remove()
• 并发读写需求：别硬改 HashMap，换 ConcurrentHashMap —— 它的迭代器是弱一致性的（fail-safe），不抛 CME，但可能漏掉或重复某些元素

为什么 ConcurrentHashMap 不抛 ConcurrentModificationException

它压根不维护全局 modCount，而是分段锁 + CAS + 迭代器基于当前桶数组快照 + 链表/红黑树节点的 volatile 引用，保证迭代过程不阻塞也不校验“是否被改”。所以不会 fail-fast，也不会完全实时一致——属于明确设计的弱一致性语义。

关键差异点：

• ConcurrentHashMap 的 iterator 不保证反映迭代开始后的任何修改（新增可能看不到，删除可能仍看到）
• 它的 size() 是估算值（多段加总可能有误差），别拿它做精确判断依据
• 不能用 iterator.remove() 删除元素（抛 UnsupportedOperationException），要删得用 map.remove(key)

复杂点在于：这种“不报错”不是因为更健壮，而是放弃了强一致性保证。如果你的业务逻辑隐含了“遍历期间结构不变”的假设（比如统计、校验、状态同步），即使没异常，结果也可能错。

本篇关于《详解集合的fail-fast与fail-safe机制_并发修改异常的触发与规避》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！