在多线程环境里，普通ArrayList一旦被一个线程遍历、另一个线程同时修改，就会抛出ConcurrentModificationException。Java并发包提供的CopyOnWriteArrayList用写时复制思路解决了这个问题：任何写操作都会复制一份新数组，完成修改后再把引用切换过去，读操作始终访问旧数组，因此读完全不需要加锁。
一、CopyOnWriteArrayList的核心原理
CopyOnWriteArrayList内部持有一个被volatile修饰的数组引用。当调用add、set、remove等写方法时，它会先获取一把ReentrantLock，防止多个写线程同时复制数组，然后在锁内把当前数组拷贝到一个长度合适的新数组，写入数据，最后把volatile引用指向新数组。由于读方法如get、iterator只读取数组引用指向的内容，且数组本身不可变，所以读操作不仅无锁，还能保证弱一致性：迭代器拿到的是创建那一刻的数组快照。
这种设计让读性能极高，适合配置列表、监听器集合、白名单等读多写少场景。但每次写都要复制整个数组，如果列表很大或写很频繁，会造成大量对象分配和GC压力。此外，迭代器不反映写后变化，若业务要求实时一致则不适用。理解这点，才能正确评估是否选用它。
二、基础用法与遍历示例
使用方式和ArrayList几乎一致，直接new即可，无需外部同步。下面代码演示了多线程下安全遍历与添加，不会出现并发修改异常：
import java.util.concurrent.CopyOnWriteArrayList;
public class COWDemo {
public static void main(String[] args) {
CopyOnWriteArrayList<String> list = new CopyOnWriteArrayList<>();
list.add("a");
list.add("b");
// 读线程遍历，无锁安全
new Thread(() -> {
for (String s : list) {
System.out.println("read: " + s);
}
}).start();
// 写线程修改，复制数组不影响正在遍历的快照
new Thread(() -> {
list.add("c");
System.out.println("added c, size=" + list.size());
}).start();
}
}
上面例子中，即便写线程在遍历开始后插入了元素c，读线程使用的仍是旧快照，不会报错，也不会看到c。如果希望读能感知最新数据，就不能依赖迭代器，而应在循环里反复调用get(i)并配合size()检查，但这样仍可能因弱一致性看到不一致的长度与内容，需要业务层容忍。
另一个常见技巧是用addIfAbsent避免重复添加，它先无锁查找，再加锁复制，适合维护去重后的监听者列表。相比自己用synchronized加锁判断，代码更简洁且读不受影响。
三、批量写入与性能注意点
如果必须连续插入多条数据，不要循环调用add，因为每次add都会复制一次数组。应使用addAll一次性复制，只产生一次数组开销：
import java.util.Arrays;
import java.util.concurrent.CopyOnWriteArrayList;
public class BatchDemo {
public static void main(String[] args) {
CopyOnWriteArrayList<Integer> list = new CopyOnWriteArrayList<>();
// 错误示范：循环add导致多次复制
// for (int i = 0; i < 1000; i++) list.add(i);
// 正确做法：批量添加，仅复制一次
list.addAll(Arrays.asList(1, 2, 3, 4, 5));
System.out.println("batch size=" + list.size());
}
}
从内存角度，写时复制意味着某一时刻新旧两个数组短暂共存，若列表存放大对象或容量千级以上，单次写就可能占用双倍空间。因此在写频繁且数据量大的场景，应改用ConcurrentLinkedQueue、ConcurrentHashMap或自己用锁控制的普通集合。
还要注意，CopyOnWriteArrayList的size、isEmpty等也是读快照，不保证与某次写操作严格同步。在监控指标里若用size判断任务完成，需接受短暂偏差，或改用AtomicInteger单独计数。
四、与其他线程安全方案的对比
用Collections.synchronizedList包装的ArrayList，读写都加同一把锁，遍历前须手动同步块，否则仍会抛异常；而CopyOnWriteArrayList遍历天然安全但慢于纯读锁。下表简要对比：
| 方案 | 读性能 | 写性能 | 遍历安全 | 数据一致性 |
|---|---|---|---|---|
| synchronizedList | 中（加锁） | 低（加锁） | 否（需手动同步） | 强一致 |
| CopyOnWriteArrayList | 高（无锁） | 低（复制数组） | 是（快照） | 弱一致 |
| ConcurrentHashMap键集 | 高 | 中 | 是（弱一致） | 弱一致 |
可以看出，当你的列表主要用于广播事件、缓存路由表、保存连接会话且很少变动时，CopyOnWriteArrayList是简单可靠的选择。若写操作占到总体百分之十以上，就要慎重评估复制成本。
实践中，很多框架如Spring的事件广播、Tomcat的监听器管理都内置了类似写时复制集合，理解其取舍能帮你在自研组件时做出合理封装，而不是盲目追求绝对线程安全却拖慢系统。
五、小结与适用建议
CopyOnWriteArrayList通过空间换时间、写时复制、 volatile数组引用，实现了读无锁且遍历不抛异常的线程安全列表。掌握它的弱一致迭代、批量写优化、避免大对象频繁复制，是应用技巧的核心。在配置类、监听类集合中使用它，代码最简洁也最稳；在高频写或海量数据下则应转向其他并发结构。
最后提醒，调用contains、indexOf等查找方法在大数据量时也是O(n)且基于快照，不要把它当高效Set使用。若需并发去重，结合ConcurrentHashMap或CopyOnWriteArraySet更为合适。
CopyOnWriteArrayList线程安全Java并发修改时间：2026-08-05 07:51:29