CopyOnWriteArrayList适用于读多写少、无需实时一致性的场景，如监听器列表；每次写操作复制全量数组，迭代器基于快照不抛ConcurrentModificationException，但不支持remove且无法感知后续写入。
什么时候该用 CopyOnWriteArrayList
它只适合「读多写少」且对实时一致性无强要求的场景。比如监听器列表、事件回调注册表、配置项的只读快照缓存——这些地方读操作可能每秒成千上万次，但添加或删除监听器一小时才发生几次。
核心判断依据是：写操作是否会引起全量数组复制。每次调用 add()、remove() 或 set()，都会创建新数组并复制全部元素。如果写操作频繁（例如每秒几十次），CPU 和 GC 压力会明显上升，反而比加锁的 ArrayList 更慢。
CopyOnWriteArrayList 的迭代器为什么不会抛 ConcurrentModificationException
因为它的迭代器基于创建时的数组快照，和原列表后续修改完全隔离。即使你在遍历过程中另一个线程调用了 add()，迭代器仍按旧数组继续走，不会感知变化，也不会失败。
这带来两个关键事实：
立即学习“Java免费学习笔记（深入）”；
- 迭代期间无法看到其他线程的写入结果
- 迭代器不支持
remove()（调用会抛UnsupportedOperationException）
CopyOnWriteArrayListlist = new CopyOnWriteArrayList<>(); list.add("a"); list.add("b"); Iterator it = list.iterator(); list.add("c"); // 这个新增对 it 完全不可见 while (it.hasNext()) { System.out.println(it.next()); // 只输出 "a" 和 "b" }
和 synchronized(new ArrayList()) 或 Collections.synchronizedList() 比有什么区别
根本差异在锁粒度和读写阻塞行为：
-
Collections.synchronizedList()对每个方法加sync块，读写都串行，吞吐量低 -
CopyOnWriteArrayList读操作无锁、写操作独占但不影响读，适合高并发读 - 前者能保证「强一致性」（你 add 后立刻能被下一次 get(0) 看到），后者只能保证「最终一致性」，且中间有延迟
如果你需要「写后立即可读」，别用 CopyOnWriteArrayList；如果你要的是「读不卡写、写不卡读」，它就是为此而生的。
容易被忽略的内存与可见性细节
每次写操作不仅复制数组，还触发一次 volatile 写（对底层 array 引用字段），所以新数组对所有线程立即可见——这是它线程安全的基础，不是靠 synchronized。
但要注意：数组里的元素本身不自动具备可见性。如果你存的是可变对象，比如 CopyOnWriteArrayList，多个线程修改同一个 Counter 实例的字段，仍需额外同步。
另外，大对象数组复制开销敏感：假设单个元素占 1KB，列表有 10 万条，一次 add() 就要分配并复制约 100MB 内存——这种场景下，它已不再是“安全选择”，而是性能陷阱。
