Java集合快照机制：CopyOnWrite迭代原理解析

Java集合中的CopyOnWriteArrayList通过“快照迭代”实现读写分离：调用iterator()时立即冻结当前数组副本，遍历全程基于该不可变视图，既不感知后续增删改操作，也不支持remove()/set()（直接抛出UnsupportedOperationException）；其读操作无锁高效，写操作则加锁并复制整个数组，虽保障线程安全与内存可见性，却带来O(n)写开销和潜在GC压力——特别适用于监听器列表、配置缓存等读远多于写的场景，但需警惕快照陈旧性引发的漏处理、重复消费等业务风险，以及可变对象内部状态被意外修改的隐式共享问题。

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 数组引用。

• 性能影响：写操作时间复杂度是 O(n)，频繁增删会导致 GC 压力和 CPU 浪费，别把它当普通 ArrayList 用
• 适用场景：监听器列表、配置白名单、路由规则缓存等——读频次远高于写频次（比如 1000:1）
• 内存可见性保障：靠 volatile 修饰的 array 字段，确保新数组引用对所有线程立即可见

快照机制不是银弹，要注意“陈旧性”带来的业务风险

弱一致性 ≠ 最终一致性。快照不会自动刷新，也不会通知你“数据已过期”。某些场景下，这种延迟会引发逻辑漏洞。

• 典型踩坑点：用 CopyOnWriteArrayList 存储实时告警事件，后台线程轮询迭代器消费，却因快照滞后导致重复消费或漏消费
• 判断依据：如果业务要求“看到最后一次写入后的状态”，就不能依赖迭代器，得改用 get(0) + size() 手动控制索引，或换 BlockingQueue
• 容易被忽略的细节：即使只读线程很多，每个 iterator() 都会持有一个数组引用，长期运行可能积累大量旧数组，需关注堆内存增长趋势

好了，本文到此结束，带大家了解了《Java集合快照机制：CopyOnWrite迭代原理解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！