根本原因是ArrayList迭代器采用fail-fast机制，遍历时检测到modCount被修改即抛ConcurrentModificationException；CopyOnWriteArrayList通过写时复制、读用快照绕过校验，但仅适用于读多写少场景。
为什么遍历 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<string> it = list.iterator();<br>while (it.hasNext()) {<br> String s = it.next(); // 安全<br> // it.remove(); // ❌ 不支持<br>}</string>
容易被忽略的性能陷阱
CopyOnWriteArrayList 的写操作成本不是常数级。假设当前数组长度为 n，一次 add() 会分配 n+1 长度的新数组，并拷贝全部 n 个元素。如果写操作频繁（比如每秒上百次），不仅 CPU 花在复制上，还会制造大量短生命周期对象，给 GC 带来压力。
判断是否适用，看三个信号：
- 读操作占比 > 90%
- 写操作不密集（例如配置刷新、事件注册/注销）
- 元素数量不大（几百以内），否则单次复制开销明显
如果写操作稍多，或元素较大，考虑用 ConcurrentHashMap 模拟列表语义，或用 ReentrantLock + 普通 ArrayList 手动加锁——别为了“看起来线程安全”而滥用 CopyOnWriteArrayList。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
