什么是Java集合的快照机制_理解CopyOnWrite容器的迭代逻辑

顺亿

2026-10-15 • 👁 0人浏览过

CopyOnWriteArrayList.iterator() 返回不可变快照，遍历基于创建时的数组副本，无法感知后续增删改操作；不支持remove()/set()，调用抛UnsupportedOperationException；读无锁、写加锁并复制数组，适用于读多写少场景。 CopyOnWriteArrayList.iterator() 返回的是快照，不是实时视图调用

iterator()

时，它立刻把当前底层数组的引用“冻结”下来，后续遍历全部基于这个不可变副本。这意味着：你加了新元素、删了旧元素、甚至清空了整个列表，只要迭代器已经创建，它就完全感知不到。常见错误现象：

ConcurrentModificationException

没有抛出，但业务逻辑误以为能“边读边看最新状态”，结果漏处理新增项真实行为示例：主线程调用

list.iterator()

后，子线程执行

list.add("X")

，主线程迭代器仍只输出旧数据关键约束：该快照是

Object[]

引用拷贝，不是深拷贝；若数组里存的是可变对象（如

StringBuilder

），其内部状态仍可能被其他线程修改为什么迭代器不支持

remove()

和

set()

因为快照本身是只读视图——它持有的是某个历史时刻的数组引用，没有关联任何写锁或更新路径。调用这些方法没有意义，也不安全。直接后果：所有结构性修改方法都会抛出

UnsupportedOperationException

，不是设计疏漏，而是机制使然替代做法：需要删除时，应改用

list.removeIf(...)

或先收集待删元素再批量调用

list.removeAll(...)

注意陷阱：别在

for-each

循环里写

list.remove(...)

，虽然语法合法，但会跳过下一个元素（因索引偏移）写操作触发复制，但读操作全程无锁

add()

、

remove()

等写方法内部用

ReentrantLock

加锁，并调用

Arrays.copyOf()

创建新数组；而

get()

、

iterator()

、

size()

全部无锁，直接读取 volatile 数组引用。 Eclipse导入Android或其他的JAVA项目的正确方法 WORD版本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看下载性能影响：写操作时间复杂度是

O(n)

，频繁增删会导致 GC 压力和 CPU 浪费，别把它当普通

ArrayList

用适用场景：监听器列表、配置白名单、路由规则缓存等——读频次远高于写频次（比如 1000:1）内存可见性保障：靠

volatile

修饰的

array

字段，确保新数组引用对所有线程立即可见快照机制不是银弹，要注意“陈旧性”带来的业务风险弱一致性 ≠ 最终一致性。快照不会自动刷新，也不会通知你“数据已过期”。某些场景下，这种延迟会引发逻辑漏洞。立即学习 “ Java免费学习笔记（深入） ”；典型踩坑点：用

CopyOnWriteArrayList

存储实时告警事件，后台线程轮询迭代器消费，却因快照滞后导致重复消费或漏消费判断依据：如果业务要求“看到最后一次写入后的状态”，就不能依赖迭代器，得改用

get(0)

size()

手动控制索引，或换

BlockingQueue

容易被忽略的细节：即使只读线程很多，每个

iterator()

都会持有一个数组引用，长期运行可能积累大量旧数组，需关注堆内存增长趋势

相关文章