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<String> list = new CopyOnWriteArrayList<>();
list.add("a");
Iterator<String> 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<map.entry>> it = map.entrySet().iterator()</map.entry>，然后调it.remove() - 并发读写需求：别硬改
HashMap，换ConcurrentHashMap—— 它的迭代器是弱一致性的（fail-safe），不抛 CME，但可能漏掉或重复某些元素
为什么 ConcurrentHashMap 不抛 ConcurrentModificationException
它压根不维护全局 modCount，而是分段锁 + CAS + 迭代器基于当前桶数组快照 + 链表/红黑树节点的 volatile 引用，保证迭代过程不阻塞也不校验“是否被改”。所以不会 fail-fast，也不会完全实时一致——属于明确设计的弱一致性语义。
关键差异点：
-
ConcurrentHashMap的iterator不保证反映迭代开始后的任何修改（新增可能看不到，删除可能仍看到） - 它的
size()是估算值（多段加总可能有误差），别拿它做精确判断依据 - 不能用
iterator.remove()删除元素（抛UnsupportedOperationException），要删得用map.remove(key)
复杂点在于：这种“不报错”不是因为更健壮，而是放弃了强一致性保证。如果你的业务逻辑隐含了“遍历期间结构不变”的假设（比如统计、校验、状态同步），即使没异常，结果也可能错。
