Java并发遍历安全解决方案

本文深入剖析了Java中ArrayList并发遍历抛出ConcurrentModificationException的根本原因——并非线程不安全本身，而是其fail-fast机制主动检测并拦截遍历过程中的结构性修改；进而详解CopyOnWriteArrayList如何通过写时复制与读快照策略绕过校验，实现无锁安全遍历，但强调其仅适用于读多写少、元素量小的场景，并警示滥用风险：写操作开销大、GC压力高、传统for循环索引访问仍不安全，最后给出正确用法（增强for或显式迭代器）及替代方案建议，帮助开发者避开常见陷阱，做出理性技术选型。

为什么遍历 ArrayList 会抛 ConcurrentModificationException

根本原因是普通 ArrayList 的迭代器在创建时会记录当前 modCount（修改计数），后续每次调用 next() 都会校验该值是否被外部修改过。只要在遍历过程中有线程调用 add()、remove() 等结构性修改方法，校验失败就直接抛异常——这不是线程安全问题，而是“快速失败”（fail-fast）机制的主动拦截。

CopyOnWriteArrayList 是怎么绕过这个限制的

它不锁、不阻塞、也不校验 modCount。每次写操作（如 add()、set()、remove()）都会：复制当前底层数组 → 在副本上修改 → 用新数组原子替换旧引用。而读操作（包括 iterator()、get()、size()）始终作用于某个快照，因此遍历时哪怕其他线程正在写，也不会看到“中途被改”的数组，自然不会触发校验失败。

注意几个关键点：

• iterator() 返回的是只读快照，调用 remove() 或 add() 会抛 UnsupportedOperationException
• 写操作开销大（涉及数组复制和 GC 压力），适合「读多写少」场景，比如监听器列表、配置项缓存
• size() 返回的是当前快照长度，但遍历中新增的元素对本次迭代不可见

正确使用 CopyOnWriteArrayList 遍历的写法

最常见错误是仍用传统 for 循环配合 get(i)，误以为“没调 iterator() 就安全”——其实不然，因为 get(i) 内部仍依赖数组长度和索引，若写线程刚好扩容/缩容底层数组，可能引发 ArrayIndexOutOfBoundsException（虽然概率低，但 CopyOnWriteArrayList 并不保证这种访问的线程安全）。

推荐做法只有两种：

• 用增强 for 循环：

  for (String s : list) { ... }

  —— 底层调用 iterator()，安全
• 显式获取迭代器并遍历：

  Iterator it = list.iterator();
  while (it.hasNext()) {
      String s = it.next(); // 安全
      // it.remove(); // ❌ 不支持
  }

容易被忽略的性能陷阱

CopyOnWriteArrayList 的写操作成本不是常数级。假设当前数组长度为 n，一次 add() 会分配 n+1 长度的新数组，并拷贝全部 n 个元素。如果写操作频繁（比如每秒上百次），不仅 CPU 花在复制上，还会制造大量短生命周期对象，给 GC 带来压力。

判断是否适用，看三个信号：

• 读操作占比 > 90%
• 写操作不密集（例如配置刷新、事件注册/注销）
• 元素数量不大（几百以内），否则单次复制开销明显

如果写操作稍多，或元素较大，考虑用 ConcurrentHashMap 模拟列表语义，或用 ReentrantLock + 普通 ArrayList 手动加锁——别为了“看起来线程安全”而滥用 CopyOnWriteArrayList。

以上就是《Java并发遍历安全解决方案》的详细内容，更多关于的资料请关注golang学习网公众号！