CopyOnWriteArrayList适合读多写少、写操作不频繁的并发场景，如监听器列表、配置缓存等；写入性能差、内存开销大，不适用于高频增删或单线程普通集合。
CopyOnWriteArrayList 适合什么场景
它只适合读多写少、且写操作不频繁的并发场景。底层每次写操作（add、remove、set）都会复制整个数组，所以写入性能差、内存开销大。但读操作完全无锁，iterator() 也不会抛 ConcurrentModificationException。
典型用例：监听器列表、配置项缓存、状态广播等——这些场景往往注册/注销极少，但遍历通知极频繁。
- 不要用在高频增删的业务逻辑中（比如实时消息队列）
- 不能替代
ArrayList做普通单线程容器（没必要承担复制开销） - 迭代期间即使其他线程修改了列表，当前迭代器看到的仍是快照，不会反映最新状态
为什么不能用 CopyOnWriteArrayList 替代 ArrayList 做普通集合
两者的语义和性能特征完全不同：ArrayList 是非线程安全、轻量、支持随机访问和快速写入；CopyOnWriteArrayList 是线程安全、写时复制、迭代安全，但写入慢、内存占用翻倍（旧数组等待 GC）、不支持 listIterator() 的双向遍历。
如果你只是在单线程里用，或者已用 synchronized / ReentrantLock 保护了 ArrayList，那强行换 CopyOnWriteArrayList 只会拖慢性能、增加 GC 压力。
立即学习“Java免费学习笔记（深入）”；
-
CopyOnWriteArrayList.add()平均时间复杂度是 O(n)，而ArrayList.add()是 O(1) 均摊 -
CopyOnWriteArrayList不允许null元素（调用add(null)会抛NullPointerException），ArrayList允许 - 它的
size()和get(int)虽然快，但和ArrayList不是一个量级的“快”——前者是常数时间没错，但背后是整块堆内存的复制成本被摊到写操作上了
常见误用：在 for-each 循环里 remove 元素
很多人以为 CopyOnWriteArrayList 能解决“遍历时删除”的问题，于是写出这样的代码：
for (String s : list) {
if (s.startsWith("tmp")) {
list.remove(s); // ❌ 仍会漏删、且效率极低
}
}
这看起来不会抛异常，但实际行为是：本次迭代基于初始快照，remove() 触发复制，但新数组对当前迭代器不可见，后续元素仍按原顺序遍历——等于“删了但没完全删”。更糟的是，每次 remove() 都复制一次数组，N 次删除就复制 N 次。
- 正确做法是收集待删元素后批量调用
removeAll()，或改用Iterator.remove()（它内部委托给CopyOnWriteArrayList自己的线程安全删除逻辑） - 注意：
Iterator.remove()在CopyOnWriteArrayList中是安全的，但代价仍是复制——所以仍应避免在循环中频繁调用 - 如果真要边遍历边删，且数据量不大，不如先转成
ArrayList，用传统索引倒序删
和 Collections.synchronizedList(new ArrayList()) 的关键区别
后者是对所有方法加同一把 mutex，读写都阻塞；前者读不加锁、写才复制。这意味着：
- 高并发读 + 低频写 →
CopyOnWriteArrayList吞吐更高 - 写操作之间仍串行（因为复制过程需原子完成），但读完全不参与锁竞争
-
synchronizedList的iterator()仍需手动同步，否则可能抛ConcurrentModificationException；而CopyOnWriteArrayList.iterator()天然安全 -
synchronizedList支持所有ArrayList行为（包括null、listIterator），CopyOnWriteArrayList则做了取舍
选哪个，取决于你压测时真实瓶颈在哪——不是看“是否线程安全”，而是看“读写比”和“是否能接受写延迟与内存放大”。
