ConcurrentModificationException消失之谜，深入剖析CopyOnWriteArrayList迭代机制

原创于 2025-11-27 10:27:11 发布 · 270 阅读

CC 4.0 BY-SA版权

第一章：ConcurrentModificationException消失之谜，深入剖析CopyOnWriteArrayList迭代机制

在多线程环境下遍历集合时，ConcurrentModificationException 是开发者常遇到的异常。它通常由 ArrayList 等非线程安全集合在迭代过程中被修改所触发。然而，使用 CopyOnWriteArrayList 却能彻底规避这一问题，其背后机制值得深入探究。

写时复制的核心原理

CopyOnWriteArrayList 采用“写时复制”（Copy-On-Write）策略。每当有写操作（如添加、删除元素）发生时，它不会直接修改原数组，而是先创建一个新副本，在副本上完成修改后，再将引用指向新数组。这一过程保证了读操作始终面对的是不变的数据快照。


// 示例：添加元素时的写时复制逻辑
public boolean add(E e) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        Object[] elements = getArray();
        int len = elements.length;
        // 复制新数组并追加元素
        Object[] newElements = Arrays.copyOf(elements, len + 1);
        newElements[len] = e;
        // 原子性更新数组引用
        setArray(newElements);
        return true;
    } finally {
        lock.unlock();
    }
}

迭代器为何不抛出异常

CopyOnWriteArrayList 的迭代器基于创建时的数组快照生成，即使其他线程修改了列表，迭代器仍持有旧数组引用，因此不会检测到结构性变化，自然不会抛出 ConcurrentModificationException。

读操作无锁，性能高，适合读多写少场景
写操作需加锁且复制数组，开销较大
数据弱一致性，迭代器无法立即看到最新修改

特性	ArrayList	CopyOnWriteArrayList
线程安全	否	是
迭代时允许修改	否（抛异常）	是
适用场景	单线程或外部同步	读多写少的并发环境

第二章：CopyOnWriteArrayList迭代器核心原理

2.1 迭代器的快照机制：理解COW的核心设计

在并发编程中，迭代器常面临数据一致性问题。写时复制（Copy-on-Write, COW）通过快照机制有效解决了这一难题。

快照的生成过程

COW在迭代开始时保留原始数据的引用，仅当发生修改时才复制数据。这保证了迭代过程中视图的稳定性。


type Snapshot struct {
    data []int
}

func (s *Snapshot) Iterate() <-chan int {
    ch := make(chan int)
    go func() {
        defer close(ch)
        for _, v := range s.data { // 使用初始化时的数据副本
            ch <- v
        }
    }()
    return ch
}

上述代码中，s.data 在迭代期间保持不变，即使外部发生修改，也不会影响当前迭代流程。

触发复制的条件

写操作发生时才进行实际内存复制
读操作共享原始数据，提升性能
多版本共存，实现无锁读取

2.2 写时复制的实现细节与内存语义分析

写时复制的基本机制

写时复制（Copy-on-Write, COW）是一种延迟内存复制的优化策略。多个进程或线程最初共享同一块内存区域，仅当某个实体尝试修改数据时，系统才真正复制该页并分配独立副本。

内存页的共享与分离

操作系统通过页表项中的只读标志位实现COW。初始时，共享页标记为只读。写操作触发页错误，内核捕获后分配新页并更新页表：


// 伪代码：COW页错误处理
void handle_page_fault(struct vm_area *vma, unsigned long addr) {
    if (is_cow_page(addr)) {
        struct page *new_page = alloc_page();
        copy_page_content(old_page, new_page);
        map_virtual_address(vma, addr, new_page, WRITEABLE);
        mark_page_dirty(new_page);
    }
}

上述逻辑中，is_cow_page 判断是否为COW页，alloc_page 分配物理页，map_virtual_address 建立可写映射，确保后续写操作不再触发异常。

典型应用场景

fork() 系统调用中父子进程的内存共享
快照技术在文件系统和虚拟化中的应用
函数式数据结构中的不可变对象管理

2.3 迭代过程中修改集合的安全性保障

在遍历集合时对其进行修改可能引发并发修改异常（ConcurrentModificationException），尤其在使用快速失败（fail-fast）机制的集合类如 ArrayList 或 HashMap 时尤为常见。

安全遍历与修改策略

推荐使用支持并发访问的集合类，例如 CopyOnWriteArrayList 或 ConcurrentHashMap，它们通过内部机制保障迭代期间的数据一致性。

CopyOnWriteArrayList：写操作在副本上进行，读操作不加锁
ConcurrentHashMap：采用分段锁或 CAS 操作保证线程安全

CopyOnWriteArrayList<String> list = new CopyOnWriteArrayList<>();
for (String item : list) {
    list.add("new_item"); // 安全：不会抛出 ConcurrentModificationException
}

上述代码中，CopyOnWriteArrayList 在修改时创建新的数组副本，因此迭代器始终基于原始快照遍历，避免了数据竞争。该机制适用于读多写少的场景，但需注意其内存开销较高。

2.4 基于数组副本的遍历实践与性能观察

在某些并发敏感或数据一致性要求较高的场景中，基于数组副本进行遍历是一种常见策略。通过复制原始数组，可避免遍历时因外部修改导致的竞态问题。

副本遍历的基本实现

func traverseWithCopy(data []int) {
    copyData := make([]int, len(data))
    copy(copyData, data) // 创建副本
    for _, v := range copyData {
        process(v) // 安全处理，不受原数组变动影响
    }
}

上述代码通过 copy 函数生成独立副本，确保遍历过程不受原始切片并发写入干扰。虽然提升了安全性，但内存开销和复制耗时随之增加。

性能对比分析

方式	时间开销	内存开销	线程安全
直接遍历	低	无额外开销	否
副本遍历	中等	翻倍	是

当数据量增大时，副本创建的成本显著上升，需权衡安全与性能。

2.5 多线程环境下迭代器行为实测验证

在并发编程中，容器的迭代器是否具备线程安全性是系统稳定性的关键。Java 中普通集合如 ArrayList 的迭代器在被多个线程访问时，若结构被修改，将抛出 ConcurrentModificationException。

测试场景设计

创建两个线程：一个遍历 ArrayList，另一个向其中添加元素，观察迭代器行为。


List<String> list = new ArrayList<>();
list.add("A"); list.add("B");

new Thread(() -> {
    for (String s : list) {
        System.out.println(s);
    }
}).start();

new Thread(() -> list.add("C")).start();

上述代码极可能触发 ConcurrentModificationException，因为 ArrayList 的快速失败（fail-fast）机制会检测到并发修改。

安全替代方案对比

CopyOnWriteArrayList：写操作复制底层数组，读操作无锁，迭代器基于快照，线程安全；
Collections.synchronizedList：需外部同步迭代操作，否则仍不安全。

实测表明，仅当使用写时复制类容器时，多线程下迭代器才能安全遍历。

第三章：与传统集合迭代的对比分析

3.1 ArrayList与CopyOnWriteArrayList迭代差异实验

在并发编程中，ArrayList 与 CopyOnWriteArrayList 的迭代行为存在本质差异。当遍历过程中集合被修改时，前者会抛出 ConcurrentModificationException，而后者通过写时复制机制保证迭代安全。

数据同步机制

ArrayList：非线程安全，快速失败（fail-fast）
CopyOnWriteArrayList：线程安全，迭代期间允许修改，基于快照遍历（fail-safe）

List<String> list = new CopyOnWriteArrayList<>();
list.add("A"); list.add("B");
for (String s : list) {
    System.out.println(s);
    list.add("C"); // 允许操作，不会抛异常
}

上述代码中，迭代期间对 CopyOnWriteArrayList 的修改不会影响当前迭代视图，新元素仅对后续迭代可见，体现了其不可变快照特性。

3.2 并发修改异常触发机制的根源剖析

并发修改异常（ConcurrentModificationException）通常发生在多线程环境下对集合进行遍历时被其他线程修改结构。其核心在于**快速失败机制（fail-fast）**的实现。

数据同步机制

Java 中如 ArrayList、HashMap 等非线程安全集合通过 `modCount` 记录结构性修改次数。迭代器创建时会保存 `expectedModCount`，每次操作前校验二者一致性。

final void checkForComodification() {
    if (modCount != expectedModCount)
        throw new ConcurrentModificationException();
}

上述代码在迭代过程中执行校验，一旦发现 `modCount` 被外部操作更改，立即抛出异常。这并非真正的线程安全保护，而是一种检测机制。

触发场景示例

线程A使用Iterator遍历集合
线程B调用集合的remove()或add()方法
线程A下一次调用next()时触发检查失败

该机制无法保证多线程环境下的安全访问，仅能提示潜在的数据不一致风险。

3.3 读写一致性模型在实际场景中的权衡

强一致性与性能的博弈

在金融交易系统中，强一致性是刚性需求。数据库通常采用同步复制确保主从数据一致，但会显著增加写延迟。例如，在分布式事务中使用两阶段提交（2PC）可保证原子性，但牺牲了可用性。

// 示例：基于 Raft 的写操作流程
func (n *Node) Write(key, value string) error {
    if !n.IsLeader() {
        return Redirect(n.LeaderAddr)
    }
    // 提交日志到 Raft
    n.Raft.AppendLog(key, value)
    // 等待多数节点确认
    return n.WaitForCommit()
}

该代码展示了写入必须由 Leader 处理并等待多数派确认，保障强一致性，但引入了额外网络开销。

最终一致性适用场景

对于社交动态更新等场景，可接受短暂不一致。采用异步复制，提升响应速度。常见策略包括：

写后读绑定（Read-Your-Writes Consistency）
会话级一致性（Session Consistency）

模型	一致性强度	延迟	适用场景
强一致性	高	高	支付系统
最终一致性	低	低	内容推送

第四章：典型应用场景与最佳实践

4.1 适用于高读低写的并发场景案例解析

在高读低写的并发场景中，系统的读操作远多于写操作，典型应用如电商商品详情页、新闻资讯展示等。为提升性能，常采用读写分离与缓存机制。

读写分离架构

通过主库处理写请求，多个从库分担读请求，降低单节点压力：

主库接收写操作并同步数据至从库
读请求路由到只读从库，提升查询吞吐量
使用中间件（如MyCat）实现SQL自动分流

缓存优化策略

引入Redis作为缓存层，显著减少数据库访问频率：

// 获取商品信息示例
func GetProduct(id int) *Product {
    cacheKey := fmt.Sprintf("product:%d", id)
    if data, _ := redis.Get(cacheKey); data != nil {
        return Deserialize(data) // 缓存命中
    }
    product := db.Query("SELECT * FROM products WHERE id = ?", id)
    redis.Setex(cacheKey, 3600, Serialize(product)) // 写入缓存，TTL 1小时
    return product
}

上述代码通过设置缓存过期时间平衡一致性与性能，适用于更新不频繁但访问量大的数据。

4.2 监听器列表管理中的安全发布模式

在并发环境中管理监听器列表时，必须确保注册、注销与通知操作的线程安全性。常见的竞态条件出现在遍历过程中修改集合，因此需采用安全发布模式。

使用不可变副本发布监听器列表

通过每次写操作创建新副本，并以原子方式更新引用，可避免显式锁竞争：

private volatile List listeners = Collections.emptyList();

public void register(EventListener listener) {
    List newListeners = new ArrayList<>(listeners);
    newListeners.add(listener);
    this.listeners = Collections.unmodifiableList(newListeners);
}

public void notify(Event event) {
    for (EventListener listener : listeners) {
        listener.onEvent(event);
    }
}

上述代码利用 volatile 引用保证可见性，读操作无需加锁，写操作通过复制实现线程隔离，适合读多写少场景。

适用场景对比

高频率事件通知：优先选择无锁读取
频繁注册/注销：考虑使用 CopyOnWriteArrayList
资源敏感环境：权衡内存开销与同步成本

4.3 避免迭代副作用：编程实践建议

在迭代过程中修改被遍历的数据结构，容易引发不可预测的行为。为避免此类副作用，应优先采用不可变操作和函数式编程范式。

使用不可变数据结构

通过创建新对象而非修改原对象，可有效隔离副作用：


const numbers = [1, 2, 3];
const doubled = numbers.map(n => n * 2); // 返回新数组
// 原数组 numbers 保持不变

map() 方法不修改原数组，返回全新实例，确保迭代过程纯净。

避免在循环中修改索引状态

不要在 for 或 while 循环中动态增减元素
优先使用 filter()、reduce() 等高阶函数替代手动遍历

模式	是否安全	说明
map/filter/reduce	是	返回新数据，无副作用
for + splice	否	修改原数组，易出错

4.4 性能瓶颈识别与替代方案选型指导

在系统演进过程中，准确识别性能瓶颈是优化的前提。常见的瓶颈包括CPU密集型计算、I/O阻塞、内存泄漏及数据库连接池耗尽等。

典型瓶颈识别方法

使用APM工具（如SkyWalking、Prometheus）监控响应延迟与吞吐量趋势
通过pprof分析Go程序的CPU与堆内存使用情况
日志埋点结合ELK栈追踪慢请求链路

代码级性能分析示例


import _ "net/http/pprof"
// 启动后访问 /debug/pprof 可获取运行时指标

该代码启用Go内置性能剖析服务，可生成CPU、堆、goroutine等剖面数据，辅助定位热点函数。

替代方案选型对比

场景	原方案	替代方案	性能提升
JSON解析	encoding/json	goccy/go-json	~40%
ORM查询	GORM	ent或原生SQL	~30%

第五章：结语：从现象到本质，重构并发认知

理解并发模型的本质差异

现代并发编程中，线程、协程与事件循环代表了不同的抽象层级。以 Go 语言的 goroutine 为例，其轻量级特性使得启动数万个并发任务成为可能：


func worker(id int, jobs <-chan int, results chan<- int) {
    for job := range jobs {
        results <- job * 2
    }
}

// 启动3个worker处理管道任务
for w := 1; w <= 3; w++ {
    go worker(w, jobs, results)
}