CopyOnWriteArrayList读不阻塞写，因读操作访问旧数组快照，写操作新建数组；读极快且线程安全，写代价高、迭代器弱一致性；适用于读多写少场景，set与add同样昂贵，迭代器remove不支持。
CopyOnWriteArrayList 读操作为什么不会阻塞写操作
因为每次写操作（如 add、remove）都会新建数组，而读操作（如 get、iterator）始终访问的是旧数组的快照。写和读不共享同一份数据引用，天然隔离。
这带来两个关键事实：
- 读操作极快，且绝对线程安全，不需要加锁
- 写操作代价高：每次修改都要
Arrays.copyOf整个底层数组，内存和 CPU 开销随集合大小线性增长 - 迭代器是弱一致性的——它看不到写操作对当前快照之后的修改，也不会抛
ConcurrentModificationException
典型误用场景：在循环中边遍历边调用 add，以为能实时反映新元素——实际不会，因为迭代器绑定的是创建时的数组副本。
什么时候该用 CopyOnWriteArrayList 而不是 ArrayList 或 Vector
只在「读多写少 + 读操作对实时性要求不高」的场景下才合适。比如监听器列表、配置白名单、静态路由表等几乎只读、偶尔更新的数据结构。
立即学习“Java免费学习笔记（深入）”；
不适合的场景包括：
- 集合元素数量大（> 1000），写操作频繁（如每秒多次
add）——GC 压力和复制开销会明显上升 - 需要强一致性读取（例如金融对账），因为它无法保证读到最新状态
- 替代
Vector作为通用线程安全列表——Vector是方法级同步，虽慢但写操作不复制；盲目替换可能让写性能更差
对比 ArrayList：它本身不线程安全；对比 Collections.synchronizedList：读写都串行化，吞吐低但强一致；CopyOnWriteArrayList 是用空间换读并发，不是万能替代品。
add 和 set 方法的底层行为差异容易被忽略
add 总是触发数组复制，而 set 只有在索引合法时才直接修改原数组——等等，不对。实际上，set 也走复制流程：它先获取当前数组，再新建数组，把新值写入对应位置，其余元素逐个拷贝。
也就是说：set 不是“就地修改”，它和 add 一样昂贵。常见误解是“改一个元素应该比加一个快”，但源码里两者都调用 Arrays.copyOf，区别仅在于拷贝后赋值的位置不同。
验证方式很简单：
CopyOnWriteArrayList<String> list = new CopyOnWriteArrayList<>(Arrays.asList("a", "b", "c"));
System.out.println(System.identityHashCode(list.getArray())); // 记录原始数组地址
list.set(1, "x");
System.out.println(System.identityHashCode(list.getArray())); // 地址已变
所以，高频 set 比高频 add 并不更优，别被方法名误导。
迭代器 remove 报 UnsupportedOperationException 的原因
CopyOnWriteArrayList 的 Iterator 实现类是 COWIterator，它的 remove() 方法直接抛 UnsupportedOperationException。
这不是 bug，而是设计使然：迭代器持有的是只读快照，无法反向影响原容器；如果允许 remove，就要在迭代中途触发另一次 copy，破坏快照语义，也极大增加实现复杂度。
正确做法是：
- 用普通 for 循环配合
list.remove(Object)（注意下标偏移） - 或收集待删元素，再批量调用
removeAll - 避免在 foreach 中调用
remove，否则编译期不报错，运行时报异常
这个限制常被忽略，尤其从 ArrayList 迁移代码时——ArrayList.iterator().remove() 是支持的，但这里不行。
