CopyOnWriteArrayList 不是读写分离，它采用“读不加锁+写时复制”策略：读操作无锁且快，但只能看到写开始前的快照；写操作需复制整个数组，时间复杂度O(n)，内存峰值翻倍，仅适用于读远多于写、可接受最终一致性的场景。
CopyOnWriteArrayList 不是为读写分离设计的，它用的是“读不加锁 + 写时复制”策略，和传统读写锁（如 ReentrantReadWriteLock）的读写分离有本质区别——别被名字误导。
为什么 CopyOnWriteArrayList 不等于读写分离
“读写分离”通常指读操作和写操作走不同路径、互不阻塞，比如读走共享锁、写走独占锁。而 CopyOnWriteArrayList 的读操作确实不加锁，但它的“写”不是在原结构上修改，而是：new 一个新数组 → 复制旧数据 → 修改新数组 → 原子替换引用。整个过程对读完全无感知，但也意味着每次写都触发一次完整数组拷贝。
- 读操作快且无竞争，但看到的永远是写操作开始前的快照（最终一致性，非实时）
- 写操作开销大，时间复杂度 O(n)，不适合高频写场景
- 没有读锁/写锁的协作机制，也不存在“读等待写完成”或“写等待读释放”的语义
什么场景下适合用 CopyOnWriteArrayList
它只在读远多于写、且能接受短暂 stale read 的场景中才有优势。典型例子：监听器列表、配置项订阅者集合、状态枚举缓存。
- 读操作每秒数千次，写操作几分钟才发生一次 —— 合理
- 需要遍历时不抛
ConcurrentModificationException，且不希望加锁影响读吞吐 —— 合理 - 写操作频繁（如每秒多次 add/remove）或元素很大（如每个元素是 MB 级对象）—— 不合理，GC 和复制成本会飙升
- 要求强一致性（比如写完立刻要被所有读线程看到最新值）—— 不合理，因为写操作完成前，其他线程仍可能读到旧数组
和 ReentrantReadWriteLock + ArrayList 对比的关键差异
真想做读写分离，更常见的做法是自己封装 ArrayList + ReentrantReadWriteLock。但这和 CopyOnWriteArrayList 行为完全不同：
- 读操作需显式调用
readLock().lock()/unlock()，虽轻量但仍有上下文切换开销 - 写操作阻塞所有新读请求，直到写完成；而
CopyOnWriteArrayList的写不阻塞任何读 - 内存占用：前者始终一份数据；后者在写过程中存在两份数组（旧 + 新），峰值内存翻倍
- 迭代安全：用读写锁时，若在
lock内迭代，没问题；但若只读不锁，仍可能遇到ConcurrentModificationException
示例片段对比：
// CopyOnWriteArrayList：读无需锁，天然安全
CopyOnWriteArrayList<String> list = new CopyOnWriteArrayList<>();
list.add("a"); // 触发 copy
for (String s : list) { ... } // 永远不会抛 CME
// 手写读写锁版本：读必须加锁才安全
ArrayList<String> data = new ArrayList<>();
ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
// 读
lock.readLock().lock();
try {
for (String s : data) { ... }
} finally {
lock.readLock().unlock();
}
容易被忽略的三个坑
很多人以为用了 CopyOnWriteArrayList 就高枕无忧，其实几个边界问题很隐蔽：
-
size()和isEmpty()返回的是当前快照值，但紧接着调用get(0)可能因其他线程刚清空而抛IndexOutOfBoundsException—— 它不保证方法间原子性 - 批量操作如
addAll()、removeAll()仍是逐个复制，不是原子的“整体替换”，中间状态对外不可见，但性能更差 - 无法替代
ConcurrentHashMap做 key-value 存储，也没有computeIfAbsent这类原子更新能力；它只是线程安全的 List，仅此而已
真正需要读写分离语义时，先想清楚：你要的是“读不阻塞写”，还是“写不阻塞读”，还是“读写各自可并发”——CopyOnWriteArrayList 只满足第二个，而且代价明确。别为了名字里的 “CopyOnWrite” 就默认它适合你的写负载。
