CopyOnWriteArrayList读写分离原理解析

CopyOnWriteArrayList 通过“读写分离”实现高并发读取——读操作始终访问写入前的数组快照，无需加锁、零阻塞且线程安全；而每次写操作（包括看似轻量的 set）都需复制整个底层数组，带来显著的内存与CPU开销，迭代器也仅提供弱一致性保障且不支持 remove。它并非通用线程安全替代品，仅适合读极多、写极少、对实时性要求不高的场景（如监听器列表、静态配置），一旦误用于大数据量或高频写入，性能将急剧恶化，甚至比 Vector 更差——理解其“用空间换读并发”的本质，才能避免常见陷阱与性能反模式。

CopyOnWriteArrayList 读操作为什么不会阻塞写操作

因为每次写操作（如 add、remove）都会新建数组，而读操作（如 get、iterator）始终访问的是旧数组的快照。写和读不共享同一份数据引用，天然隔离。

这带来两个关键事实：

• 读操作极快，且绝对线程安全，不需要加锁
• 写操作代价高：每次修改都要 Arrays.copyOf 整个底层数组，内存和 CPU 开销随集合大小线性增长
• 迭代器是弱一致性的——它看不到写操作对当前快照之后的修改，也不会抛 ConcurrentModificationException

典型误用场景：在循环中边遍历边调用 add，以为能实时反映新元素——实际不会，因为迭代器绑定的是创建时的数组副本。

什么时候该用 CopyOnWriteArrayList 而不是 ArrayList 或 Vector

只在「读多写少 + 读操作对实时性要求不高」的场景下才合适。比如监听器列表、配置白名单、静态路由表等几乎只读、偶尔更新的数据结构。

不适合的场景包括：

• 集合元素数量大（> 1000），写操作频繁（如每秒多次 add）——GC 压力和复制开销会明显上升
• 需要强一致性读取（例如金融对账），因为它无法保证读到最新状态
• 替代 Vector 作为通用线程安全列表——Vector 是方法级同步，虽慢但写操作不复制；盲目替换可能让写性能更差

对比 ArrayList：它本身不线程安全；对比 Collections.synchronizedList：读写都串行化，吞吐低但强一致；CopyOnWriteArrayList 是用空间换读并发，不是万能替代品。

add 和 set 方法的底层行为差异容易被忽略

add 总是触发数组复制，而 set 只有在索引合法时才直接修改原数组——等等，不对。实际上，set 也走复制流程：它先获取当前数组，再新建数组，把新值写入对应位置，其余元素逐个拷贝。

也就是说：set 不是“就地修改”，它和 add 一样昂贵。常见误解是“改一个元素应该比加一个快”，但源码里两者都调用 Arrays.copyOf，区别仅在于拷贝后赋值的位置不同。

验证方式很简单：

CopyOnWriteArrayList 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() 是支持的，但这里不行。

本篇关于《CopyOnWriteArrayList读写分离原理解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！