遍历集合时抛 concurrentmodificationexception 是因迭代器检测到 modcount 与 expectedmodcount 不一致；安全删除方式有：①用 iterator.remove()；②收集后批量移除；③倒序索引遍历；多线程须换线程安全集合或加锁。

为什么遍历集合时会抛 ConcurrentModificationException

Java 的 ArrayList、HashMap 等非线程安全集合，在迭代器遍历时会检查 modCount（修改计数）是否与创建迭代器时的 expectedModCount 一致。只要在遍历过程中有其他线程或同一线程调用 add()、remove()、clear() 等结构性修改方法，就会触发该异常。

遍历时安全删除元素的三种实操方式

核心原则：别在 for-each 或普通 for (int i = 0; ...) 循环里直接调用集合的 remove() 方法。

• 用迭代器自身的 remove() 方法 —— 唯一被设计为“边遍历边删”的合法方式：

  Iterator<string> it = list.iterator();
  while (it.hasNext()) {
      String s = it.next();
      if (s.startsWith("a")) it.remove(); // ✅ 安全
  }</string>

• 收集待删元素，遍历结束后批量移除：

  List<string> toRemove = new ArrayList();
  for (String s : list) {
      if (s.length() > 5) toRemove.add(s);
  }
  list.removeAll(toRemove); // ✅ 避开迭代过程中的修改</string>

• 倒序索引遍历（仅适用于 ArrayList 等支持随机访问的集合）：

  for (int i = list.size() - 1; i >= 0; i--) {
      if (list.get(i).isEmpty()) list.remove(i); // ✅ 索引不会因前面元素删除而错位
  }

多线程环境下必须换集合类型

单线程里用 Iterator.remove() 能解决问题，但多线程下仍可能因其他线程并发修改而报错。这时不能靠“技巧”规避，必须换线程安全实现：

• 读多写少 → 用 Collections.unmodifiableList() + 外部同步，或改用 CopyOnWriteArrayList（注意：写操作开销大，适合迭代远多于修改的场景）
• 读写均衡 → 用 ConcurrentHashMap（注意它不保证遍历时的强一致性，但不会抛 ConcurrentModificationException）
• 需要强一致性 + 高并发 → 手动加锁（如 synchronized(list)），但要小心死锁和性能瓶颈

Stream API 的 filter() 不等于线程安全

有人误以为用 list.stream().filter(...).collect(...) 就能绕过并发问题 —— 实际上它只是生成新集合，并不改变原集合结构，所以不会触发 ConcurrentModificationException；但它**不解决并发修改本身**：如果另一线程正在往原集合里 add 元素，stream 过程中看到的数据仍是不一致的（可能漏掉新元素，也可能因扩容失败而抛 ArrayIndexOutOfBoundsException）。

真正关键的不是“怎么遍历不报错”，而是“谁在什么时候改了这个集合”。很多线上问题最后都卡在没理清修改源头 —— 比如一个 static List 被多个 service 方法共享修改，却只在某处加了迭代保护。