如何通过 CopyOnWriteArrayList 实现读写分离的线程安全集合-java教程-PHP中文网

copyonwritearraylist 不是读写分离，它采用“读不加锁+写时复制”策略：读操作无锁且快，但只能看到写开始前的快照；写操作需复制整个数组，时间复杂度o(n)，内存峰值翻倍，仅适用于读远多于写、可接受最终一致性的场景。

如何通过 copyonwritearraylist 实现读写分离的线程安全集合

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();
}
</string></string>

容易被忽略的三个坑

很多人以为用了 CopyOnWriteArrayList 就高枕无忧，其实几个边界问题很隐蔽：

size() 和 isEmpty() 返回的是当前快照值，但紧接着调用 get(0) 可能因其他线程刚清空而抛 IndexOutOfBoundsException —— 它不保证方法间原子性
批量操作如 addAll()、removeAll() 仍是逐个复制，不是原子的“整体替换”，中间状态对外不可见，但性能更差
无法替代 ConcurrentHashMap 做 key-value 存储，也没有 computeIfAbsent 这类原子更新能力；它只是线程安全的 List，仅此而已