ArrayList遍历时修改会抛ConcurrentModificationException，因其迭代器采用fail-fast机制，通过校验modCount检测结构性修改；CopyOnWriteArrayList则通过写时复制+volatile引用实现安全并发读。

为什么遍历时修改 ArrayList 会抛 ConcurrentModificationException

根本不是“不能改”，而是 ArrayList 的迭代器在创建时记下了当时集合的修改计数 modCount，后续每次调用 next() 都会校验这个值是否被其他线程或本线程中途改过。一旦不一致，立刻抛异常——这是 fail-fast 机制，用来快速暴露错误，不是用来兜底的。

• 单线程里边遍历边 list.add() 或 list.remove() 也会触发，不只多线程
• 哪怕只是两个线程：一个在 for-each，另一个在 add()，就稳崩
• 它不保证数据最终一致，只保证“你乱来我马上喊停”

CopyOnWriteArrayList 是怎么绕过这个检查的

它根本不让“读”和“写”碰同一份数组。每次 add()、remove()、set() 都会：加锁 → 拷贝原数组 → 在新数组上操作 → 原子替换引用。而所有 get() 和 iterator() 都直接读旧数组，完全不加锁。

• 所以遍历时，哪怕别的线程正在 add()，你看到的仍是“快照”，不会触发 modCount 校验失败
• iterator() 返回的是只读快照迭代器，调用它的 remove() 会直接抛 UnsupportedOperationException
• 底层数组用 volatile 修饰，确保引用更新对所有线程立即可见

什么时候该用，什么时候不该用

CopyOnWriteArrayList 不是 ArrayList 的万能替代品，它是有明确适用边界的。

• ✅ 适合：读多写少（比如监听器列表、配置白名单）、写操作不频繁（每秒不超过几十次）、允许读到“短暂过期”数据
• ❌ 别用：写密集场景（如高频日志收集），每次 add() 都要 Arrays.copyOf() 整个数组，内存和 CPU 开销陡增
• ⚠️ 注意：它不保证弱一致性——比如你刚 add() 完立刻 size()，拿到的是新大小；但另一个线程还在遍历旧数组，看到的 size() 还是旧的

替代方案对比：别只会背名字

遇到 ConcurrentModificationException，光换 CopyOnWriteArrayList 不够，得看场景选对工具。

• Vector：方法全加 synchronized，读写都串行，吞吐极低，基本只用于遗留代码兼容
• Collections.synchronizedList(new ArrayList())：包装一层，读写都得手动同步块，否则 iterator() 仍可能崩；且遍历必须显式 synchronized(list)
• ConcurrentHashMap 对应的是 Map 场景，别错配到 List 上

真正要并发读写同个列表，又写得不少，就得考虑是否该换数据结构——比如用 ConcurrentLinkedQueue 做生产者-消费者，而不是硬撑一个“既要又要”的列表。