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 做生产者-消费者，而不是硬撑一个“既要又要”的列表。
