CopyOnWriteArrayList适合读多写少场景，如监听器列表、配置缓存、广播队列；写操作频繁时性能骤降，因每次写需全量复制数组；迭代时修改不抛ConcurrentModificationException，但Iterator.remove()无效。
CopyOnWriteArrayList 适合哪些场景
它只适合读多写少的并发场景，比如监听器列表、配置项缓存、广播通知队列。一旦写操作（add、remove、set）变频繁，性能会急剧下降——每次写都触发数组全量复制，时间复杂度是 O(n)，内存开销也明显增大。
常见误用：拿它当普通 ArrayList 替代品，在循环中反复 add 或 remove；或者在高吞吐实时计算任务里存储中间结果。
迭代时修改不会抛 ConcurrentModificationException
这是它最直观的优势：迭代过程完全不依赖锁，底层用的是创建快照时的数组副本，所以即使其他线程正在写，当前迭代器仍能安全遍历旧数据。
CopyOnWriteArrayList<String> list = new CopyOnWriteArrayList<>();
list.add("a");
list.add("b");
// 迭代中另一个线程调用 list.remove("a") 不会影响本次遍历
for (String s : list) {
System.out.println(s); // 输出 a, b —— 即使中途被删，也不报错也不漏
}
注意：Iterator 的 remove() 方法是空实现，调用无效；想删元素只能用 list.remove(...)，且该操作不影响当前迭代器。
立即学习“Java免费学习笔记（深入）”；
不能替代 synchronized(List) 或 Collections.synchronizedList
它和加锁方案解决的是不同问题：
-
Collections.synchronizedList保证所有操作串行执行，读写都阻塞，适合写稍多、需要强一致性（如计数器+校验）的场景 -
CopyOnWriteArrayList放弃写实时性，换得读零阻塞，适合“读绝对不能卡住”的服务端响应逻辑
典型陷阱：用 CopyOnWriteArrayList 实现“先查后改”逻辑，比如 if (!list.contains(x)) list.add(x) —— 这不是原子操作，两个线程可能同时通过 contains 判断再重复添加。
构造与初始化的几个细节
它没有带初始容量的公有构造函数，只有 CopyOnWriteArrayList() 和 CopyOnWriteArrayList(Collection) 两种方式：
- 传入
Collection时，内部会调用toArray()复制一次，如果原集合很大，这步本身就有开销 - 不能像
ArrayList那样预留空间，扩容成本固定为复制全部元素 - 不支持
null元素（add(null)会抛NullPointerException）
如果你需要预填充大量只读数据，建议直接用 Arrays.asList(...) + Collections.unmodifiableList，比 CopyOnWriteArrayList 更轻量。
真正难处理的，是那些既要动态增删、又要求迭代绝对安全、还不能接受写延迟的边界情况——这时候往往得换思路，比如用 ConcurrentHashMap 模拟 set 语义，或拆分读写路径加版本号控制。
