Java中CopyOnWriteArrayList使用方法-java教程-PHP中文网

Java中CopyOnWriteArrayList使用方法

P粉602998670

发布： 2025-09-22 22:00:02

原创

840人浏览过

CopyOnWriteArrayList适合读多写少场景，其通过写时复制实现线程安全，读操作无锁高效，并保证迭代器弱一致性，适用于监听器列表、黑白名单等不频繁修改但高频查询的场景。

java中copyonwritearraylist使用方法

Java中的

CopyOnWriteArrayList

登录后复制

，说白了，就是一种“写时复制”的线程安全列表。它的核心思想很简单：当你要修改列表内容时（比如添加、删除或修改元素），它不会直接在原列表上操作，而是先悄悄地复制一份底层数组，在新副本上完成修改，然后再把这个新副本替换掉旧的底层数组。而读取操作呢，就直接读取当前数组，不需要任何锁，所以效率非常高。这使得它特别适合那种读操作远多于写操作的并发场景。

解决方案

在我看来，

CopyOnWriteArrayList

登录后复制

的设计哲学，其实是牺牲了写操作的性能和内存开销，来换取读操作的极致并发性。它的内部实现，主要依赖于一个

ReentrantLock

登录后复制

来保护写操作的原子性，确保在替换底层数组时不会出现并发问题。

具体来说，当你调用

add()

登录后复制

方法时，它会：

获取一个全局的写锁。
获取当前的底层数组。
创建一个新数组，大小比原数组大1。
将原数组的元素复制到新数组。
将新元素添加到新数组的末尾。
将列表的内部引用指向这个新数组。
释放写锁。

这个过程，每次写入都意味着一次数组的完整复制。听起来有点“笨拙”，对吧？但正是这种“笨拙”，带来了几个关键特性：

立即学习“Java免费学习笔记（深入）”；

读操作无锁： 任何时候，多个线程都可以并发地读取列表，因为它们读取的都是一个不变的数组快照。
迭代器弱一致性： 当你获取一个
```
CopyOnWriteArrayList
```
登录后复制
的迭代器时，它拿到的是那一刻列表底层数组的一个快照。这意味着，即使其他线程在迭代器创建后修改了列表，你当前的迭代器遍历的仍然是创建时的那个版本，不会抛出
```
ConcurrentModificationException
```
登录后复制
。这在处理事件监听器列表等场景时，简直是救命稻草。
线程安全： 无需额外同步，开箱即用。

所以，如果你面对的场景是：数据列表很少变动，但被成百上千个线程频繁读取，那么

CopyOnWriteArrayList

登录后复制

几乎是你的不二之选。

CopyOnWriteArrayList

登录后复制

在哪些具体场景下能发挥最大优势？

我个人觉得，

CopyOnWriteArrayList

登录后复制

最能大放异彩的地方，往往是那些“配置类”或“监听器类”的场景。比如，我们系统里经常会有一些全局的配置列表，或者注册了一堆事件监听器。

想象一下，你有一个系统，里面有很多模块都需要监听某个事件。当这个事件发生时，你需要遍历所有注册的监听器并通知它们。这时候，监听器的注册（添加）和注销（移除）操作相对较少，但事件通知（遍历）却可能非常频繁。如果用普通的

ArrayList

登录后复制

，在遍历时有其他线程修改列表，就会抛出

ConcurrentModificationException

登录后复制

，导致程序崩溃。你不得不手动加锁，那读操作的性能就废了。

用

CopyOnWriteArrayList

登录后复制

就完全没这个问题。注册和注销时，虽然会复制数组，但毕竟不频繁，那点开销可以接受。而遍历时，因为它读取的是一个不变的快照，所以可以放心地并发遍历，完全不用担心线程安全问题，性能也极佳。

再比如，一些不经常更新的“白名单”或“黑名单”列表。系统需要频繁地检查某个用户或IP是否在名单中。这种场景下，查询操作（读）是核心，列表内容的修改（写）是次要的。

CopyOnWriteArrayList

登录后复制

在这里能提供非常高效的查询能力，同时保证了列表修改时的线程安全。

所以，核心判断标准就是：你的列表是“读多写少”吗？对数据实时性要求不是那么极致吗？如果是，那它就是你的菜。

法语写作助手

法语助手旗下的AI智能写作平台，支持语法、拼写自动纠错，一键改写、润色你的法语作文。

查看详情

CopyOnWriteArrayList

登录后复制

与

Collections.synchronizedList

登录后复制

以及

ConcurrentHashMap

登录后复制

等并发集合有何不同？

这几个家伙，虽然都是为了解决并发问题，但它们的实现思路和适用场景，简直是天壤之别。

首先说说

Collections.synchronizedList

登录后复制

。这玩意儿就像是给普通的

ArrayList

登录后复制

外面套了一层“大棉袄”，所有的方法（包括

get

登录后复制

、

add

登录后复制

、

remove

登录后复制

）都用

synchronized

登录后复制

关键字同步了。它的优点是简单粗暴，容易理解。但缺点也同样明显：性能瓶颈。因为所有操作都共享同一个锁，只要有一个线程在读或写，其他线程就得等着，并发性非常差。而且，它的迭代器也不是线程安全的，你在遍历时如果其他线程修改了列表，依然会抛

ConcurrentModificationException

登录后复制

，你还得自己手动在遍历代码块外面加锁。我个人是很少在高性能场景下用它。

然后是我们的主角

CopyOnWriteArrayList

登录后复制

。它走的是“以空间换时间，以弱一致性换高并发”的路子。读操作完全无锁，性能爆炸。写操作虽然代价高昂（复制整个数组），但换来了迭代器的“快照一致性”——遍历时不会受其他修改影响。它和

synchronizedList

登录后复制

最大的区别在于，

synchronizedList

登录后复制

是所有操作都同步，而

CopyOnWriteArrayList

登录后复制

是读写分离，读无锁。

最后是

ConcurrentHashMap

登录后复制

（以及

ConcurrentSkipListSet

登录后复制

等一系列

Concurrent*

登录后复制

集合）。这些集合的设计理念又完全不同。它们通常采用更精细的并发控制机制，比如分段锁（Java 7及以前的

ConcurrentHashMap

登录后复制

）或者CAS操作结合

synchronized

登录后复制

（Java 8的

ConcurrentHashMap

登录后复制

）。它们的目标是在保证线程安全的同时，最大化读写操作的并发性能。对于

ConcurrentHashMap

登录后复制

来说，它允许部分读写操作并发进行，写操作的粒度也比

CopyOnWriteArrayList

登录后复制

要小得多（通常只锁定哈希表中的某个桶或节点）。这意味着，在写操作频繁的场景下，

ConcurrentHashMap

登录后复制

的性能会远超

CopyOnWriteArrayList

登录后复制

。

所以，总结一下：

```
synchronizedList
```
登录后复制
：简单，但并发性能最差，迭代器不安全。
```
CopyOnWriteArrayList
```
登录后复制
：读多写少场景的利器，读性能极高，迭代器安全（快照一致性），但写操作和内存开销大。
```
ConcurrentHashMap
```
登录后复制
：读写并发性能都很好，适用于各种高并发场景，但它是Map结构，不是List。

选择哪个，完全取决于你的具体业务场景和对性能、一致性的权衡。

使用

CopyOnWriteArrayList

登录后复制

时，有哪些常见的陷阱或需要注意的问题？

尽管

CopyOnWriteArrayList

登录后复制

在特定场景下非常强大，但它也不是万能药，使用不当反而会引入新的问题。我总结了几点，大家在用的时候一定要心里有数：

内存开销巨大： 这是最显而易见的。每次写入操作都会复制整个底层数组。如果你的列表非常大，且写操作比较频繁，那么内存开销会非常惊人，甚至可能导致频繁的GC，进而影响系统性能。想象一个存储了百万级对象的
```
CopyOnWriteArrayList
```
登录后复制
，每次修改都要复制百万级对象，这简直是噩梦。
写操作性能低下： 同样是由于数组复制，写入操作的性能会随着列表大小的增加而线性下降。如果你有一个写多读少的场景，或者写操作频率很高，那么
```
CopyOnWriteArrayList
```
登录后复制
的性能会非常糟糕，甚至可能比
```
synchronizedList
```
登录后复制
还差。
数据滞后性（弱一致性）： 这是一个非常重要的特性，但也是一个潜在的陷阱。由于读操作读取的是列表的一个快照，这意味着你读到的数据可能不是最新的。如果你的业务逻辑对数据的实时性要求非常高，比如需要立即反映最新的修改，那么
```
CopyOnWriteArrayList
```
登录后复制
可能就不适合，你需要考虑其他强一致性的并发集合。
元素的可变性问题：
```
CopyOnWriteArrayList
```
登录后复制
存储的是元素的引用。如果列表中的元素本身是可变对象，并且你在获取到这个对象后修改了它的内部状态，那么所有持有这个对象引用的地方都会看到这个修改。
```
CopyOnWriteArrayList
```
登录后复制
只能保证列表结构（元素的添加、删除、替换）的线程安全，不能保证列表中元素的内部状态的线程安全。如果你需要确保元素的完全不变性，那么列表中的元素本身也应该是不可变对象。
remove
登录后复制
、
contains
登录后复制
等操作依赖
equals()
登录后复制
方法：和其他
```
List
```
登录后复制
实现一样，
```
remove(Object o)
```
登录后复制
和
```
contains(Object o)
```
登录后复制
方法依赖于元素的
```
equals()
```
登录后复制
方法来判断是否相等。如果你的自定义对象没有正确实现
```
equals()
```
登录后复制
和
```
hashCode()
```
登录后复制
，可能会导致预料之外的行为，比如无法正确移除或查找元素。
迭代器的“意外”行为： 前面提到，迭代器是基于快照的。这在很多场景下是优点，但有时也可能让人困惑。比如，你期望在遍历时能看到其他线程的最新修改，但实际上却看不到。这需要开发者对
```
CopyOnWriteArrayList
```
登录后复制
的这种“弱一致性”有清晰的理解。