Java集合并发修改错误解决方法

Java集合的ConcurrentModificationException并非偶然报错，而是Fail-Fast机制主动发出的“危险信号”——它通过比对modCount与expectedModCount，在单线程遍历中调用集合自身remove()等结构性修改方法时立即中断执行，以此暴露潜在的逻辑错误或竞态风险；文章深入剖析其触发原理，给出单线程下安全删除的三大可靠方案（Iterator.remove、倒序遍历、预收集批量删），并明确多线程场景应优先选用CopyOnWriteArrayList、ConcurrentHashMap等真正线程安全的替代品，而非依赖同步包装或吞掉异常掩盖问题，强调Fail-Fast的本质是设计上的善意提醒，而非缺陷。

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 it = list.iterator();
  while (it.hasNext()) {
      String s = it.next();
      if (s.startsWith("a")) it.remove(); // ✅ 安全
  }

• 倒序 for 循环：避免索引偏移，适合按条件删多个，但不能用增强 for
  

  for (int i = list.size() - 1; i >= 0; i--) {
      if (list.get(i).startsWith("a")) list.remove(i); // ✅ 安全

• 收集待删项再批量删：适合条件复杂、删除量大的情况，注意别用 removeAll() 传原集合引用（可能引发死循环）
  

  List toRemove = new ArrayList<>();
  for (String s : list) {
      if (s.length() > 5) toRemove.add(s);
  }
  list.removeAll(toRemove); // ✅ 安全（前提是 toRemove 是新 List）

多线程环境下该选哪个并发集合

别硬套 synchronized 或手动加锁，优先用 JDK 自带的线程安全替代品，它们内部处理了 modCount 逻辑或干脆不校验。

• 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 后简单吞掉异常，却没修复逻辑本身。

到这里，我们也就讲完了《Java集合并发修改错误解决方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！