CopyOnWriteArrayList线程安全与使用场景解析

“纵有疾风来，人生不言弃”，这句话送给正在学习文章的朋友们，也希望在阅读本文《CopyOnWriteArrayList适用场景及线程安全解析》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新文章相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

CopyOnWriteArrayList适合读多写少场景，通过写时复制实现线程安全，读无锁但写开销大、内存占用高，不支持迭代中删除，仅提供最终一致性。

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

它内部通过“写时复制”实现线程安全，每次 add、remove 都会新建数组并复制全部元素，所以写操作开销大，但读操作完全无锁、不阻塞。典型适用场景包括：监听器列表（如 Swing 事件监听、Netty 的 ChannelHandler 管理）、配置项订阅者集合、白名单/黑名单缓存等——这些场景通常初始化后极少修改，但被高频遍历或迭代。

反例：如果每秒执行几十次 add 或 remove，尤其集合大小超过几百，会明显拖慢吞吐，并引发频繁 GC。

迭代过程不会抛出 ConcurrentModificationException

因为迭代器持有的是快照数组，即使其他线程正在修改列表，Iterator 仍能安全完成遍历。这点和 ArrayList + synchronized 或 Collections.synchronizedList 不同——后者在遍历时若发生结构变更，几乎必然触发 ConcurrentModificationException。

注意：Iterator.remove() 是无效操作，调用后会抛出 UnsupportedOperationException；它不支持边遍历边删除。

• 遍历时需要过滤或删除？必须先收集待删元素，遍历结束后再调用 removeAll()
• 不能依赖迭代器的实时性：你看到的永远是“开始迭代那一刻”的状态

不适用于需要强一致性或低延迟写入的场景

CopyOnWriteArrayList 的写操作不是原子的：从修改开始到新数组替换旧引用之间存在短暂窗口，且读线程可能读到旧版本。它提供的是最终一致性，而非实时一致性。

常见误用：

• 当作计数器或状态开关（如 isRunning = list.isEmpty()）——结果可能滞后
• 在实时风控逻辑中维护“当前活跃会话列表”，因写延迟导致误判
• 与 size() 配合做条件判断（如 if (list.size() > 0) list.get(0)），可能因中间被清空而抛 IndexOutOfBoundsException

这类需求更适合 ConcurrentLinkedQueue、BlockingQueue 或显式加锁控制。

替代方案对比：什么时候该选别的容器？

不要只看“线程安全”四个字就默认选 CopyOnWriteArrayList。实际选型要看访问模式：

• 读多写少 + 迭代频繁 → CopyOnWriteArrayList
• 读写均衡 + 需要低延迟写入 → ConcurrentHashMap（把索引当 key，或改用键值结构）
• 高并发写 + 允许阻塞读 → ReentrantLock 包裹普通 ArrayList（比 CopyOnWrite 更省内存）
• 纯生产-消费模型 → ArrayBlockingQueue 或 LinkedBlockingQueue

最常被忽略的一点：它的内存占用是普通 ArrayList 的两倍（写操作期间新旧数组共存），且老数组等待 GC 回收——在堆内存紧张或对象生命周期长的系统里，这点影响远超预期。

好了，本文到此结束，带大家了解了《CopyOnWriteArrayList线程安全与使用场景解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！