CopyOnWriteArrayList适用场景与原理详解

CopyOnWriteArrayList 是一种专为“读多写少”并发场景优化的线程安全列表，其核心在于读操作零锁、高性能且迭代器永不抛 ConcurrentModificationException，而写操作则通过复制整个数组实现——虽保障了读的极致效率和弱一致性，却带来显著内存开销、写吞吐瓶颈和延迟不可控等代价；它绝非 ArrayList 的简单线程安全替代品，也不适用于高频变更、强实时性或内存敏感的场景，真正适合的是监听器注册表、静态配置缓存、日志处理器列表等“几乎只读、极少修改”的典型用例，用错反而会导致 GC 压力飙升、性能断崖式下跌。

CopyOnWriteArrayList 适合读多写少的并发场景

它只在写操作（add、remove、set）时复制整个底层数组，读操作（get、iterator、size）完全无锁。这意味着：读性能极高、线程安全、迭代器不会抛 ConcurrentModificationException；但写操作开销大、内存占用翻倍、且写操作之间互斥（本质是用 ReentrantLock 串行化）。

典型适用场景包括：

• 监听器列表（如 GUI 事件回调、Spring ApplicationListener），注册/注销极少，遍历通知极频繁
• 配置项白名单、状态枚举缓存等静态或低频变更的只读集合
• 日志收集器中的 handler 列表，启动后基本不增删

不适合：高频增删、实时性要求强（写操作延迟不可控）、内存敏感（每次写都新建数组，旧数组待 GC）。

为什么不能用它替代 ArrayList 或 ConcurrentHashMap

CopyOnWriteArrayList 和 ArrayList 不是简单“线程安全版”，而是设计哲学完全不同：

• ArrayList 是可变、非线程安全、零拷贝；CopyOnWriteArrayList 是写时复制、读快写慢、天然弱一致性（读不到最新写入）
• ConcurrentHashMap 支持高并发读写，但它是 Map；若你需要的是「有序、可重复、支持随机索引访问」的并发 List，它无法替代
• 它不支持 list.iterator().remove() —— 迭代器的 remove() 方法直接抛 UnsupportedOperationException

常见误用：用它存实时订单列表、高频更新的用户会话 ID 集合——结果是 GC 压力陡增、写吞吐骤降、数据延迟明显。

底层 add() 操作到底做了什么

调用 add(E) 时，会触发完整数组复制流程：

final Object[] newElements = Arrays.copyOf(elements, len + 1);
newElements[len] = e;
setArray(newElements);

关键点：

• 复制开销与当前数组长度成正比，不是常数时间；10 万元素时一次 add 可能分配并拷贝 ~800KB 内存
• setArray() 使用 volatile 写，保证新数组对所有线程可见，但不保证之前所有写操作的全局顺序（JMM 层面）
• 所有写方法（add、remove、set）共用同一把 ReentrantLock，写操作完全串行，不存在并发写竞争，但也失去了写并行能力

迭代器返回的是快照，不是实时视图

iterator() 返回的 COWIterator 在构造时就持有了当前数组的引用副本，后续无论原列表如何修改，迭代器看到的始终是创建那一刻的状态。

这导致两个易忽略行为：

• 在迭代过程中调用 list.add(x)，该元素一定不会出现在本次迭代中
• 多个线程同时迭代同一个 CopyOnWriteArrayList，彼此看到的“快照”可能来自不同写操作之后，彼此之间没有 happens-before 关系

所以它适合“遍历时不关心中间变更”的场景，比如广播通知、批量导出快照——不适合实现类似“边遍历边过滤删除”的逻辑（应改用 ConcurrentLinkedQueue 或加显式锁）。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《CopyOnWriteArrayList适用场景与原理详解》文章吧，也可关注golang学习网公众号了解相关技术文章。