ConcurrentModificationException 的根本原因是 modCount 与 expectedModCount 不一致，触发 Java 集合的 Fail-Fast 机制；单线程遍历中调用集合自身 remove() 等结构性修改方法即会抛出该异常。
ConcurrentModificationException 是怎么被触发的
根本原因在于 modCount 和 expectedModCount 不一致。Java 集合（如 ArrayList、HashMap）在迭代器初始化时会把当前集合的修改计数 modCount 赋值给迭代器的 expectedModCount；后续每次调用 next() 或 remove() 前，都会检查二者是否相等。一旦外部线程或同一线程其他代码调用了 add()、remove() 等结构性修改方法，modCount 就会自增，而迭代器并不知情，下次校验就直接抛 ConcurrentModificationException。
这不是线程安全问题的“报错”，而是 Fail-Fast 机制主动中断——哪怕单线程里边遍历边删元素也会触发。
- 常见错误现象：
Exception in thread "main" java.util.ConcurrentModificationException，堆栈指向ArrayList$Itr.checkForComodification或类似位置 - 典型场景：用增强 for 循环或显式
Iterator遍历时，调用集合自身的remove()方法（不是Iterator.remove()） - 注意：
get()、set()不改变结构，不会触发；但clear()、addAll()、retainAll()都会
单线程下安全删除元素的三种写法
别碰 list.remove(obj)，改用迭代器自带的删除方式，或者换数据结构，或者预收集索引。
- 用
Iterator.remove()：最直观，仅适用于需要逐个判断后删除的场景Iterator<String> it = list.iterator();<br>while (it.hasNext()) {<br> String s = it.next();<br> if (s.startsWith("a")) it.remove(); // ✅ 安全<br>} - 倒序 for 循环：避免索引偏移，适合按条件删多个，但不能用增强 for
for (int i = list.size() - 1; i >= 0; i--) {<br> if (list.get(i).startsWith("a")) list.remove(i); // ✅ 安全 - 收集待删项再批量删：适合条件复杂、删除量大的情况，注意别用
removeAll()传原集合引用（可能引发死循环）List<String> toRemove = new ArrayList<>();<br>for (String s : list) {<br> if (s.length() > 5) toRemove.add(s);<br>}<br>list.removeAll(toRemove); // ✅ 安全（前提是 toRemove 是新 List）
多线程环境下该选哪个并发集合
别硬套 synchronized 或手动加锁，优先用 JDK 自带的线程安全替代品，它们内部处理了 modCount 逻辑或干脆不校验。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
-
CopyOnWriteArrayList：读多写少场景。每次写操作都复制底层数组，迭代器基于快照，所以遍历时增删不会抛异常，但内存开销大、实时性差 -
ConcurrentHashMap：不要用keySet().iterator()遍历后删 key，改用computeIfPresent()或remove(key, value)；若必须遍历，用forEach()或entrySet().parallelStream() - 别用
Collections.synchronizedList()+ 迭代器：它只同步单个方法，iterator()返回的仍是普通迭代器，依然会触发ConcurrentModificationException - 性能提示：
CopyOnWriteArrayList的add()是 O(n)，ConcurrentHashMap的迭代不保证强一致性，可能漏掉刚 put 的 entry
为什么 Vector 和 Hashtable 没有这个异常
因为它们压根没实现 Fail-Fast。它们的 iterator() 方法返回的是普通枚举器（Enumeration），且所有 public 方法都加了 synchronized，迭代过程不会校验 modCount ——但这不等于线程安全，只是“不报错”。比如两个线程同时 next() 和 remove()，结果不可预测，可能跳过元素或 NPE。
所以别因为没异常就认为能用，Vector 已是历史遗留，现代代码应避开。
真正容易被忽略的是：Fail-Fast 不是 bug，是设计选择；它提醒你“这里存在潜在竞态”，而不是帮你掩盖问题。很多线上事故，恰恰始于开发者 catch 住 ConcurrentModificationException 后简单吞掉异常，却没修复逻辑本身。
