如何利用 CopyOnWriteArrayList 的读写分离机制实现在高频读、极低频写场景下的无锁化访问

如何利用 CopyOnWriteArrayList 的读写分离机制实现在高频读、极低频写场景下的无锁化访问

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

在高并发编程中，找到一个既保证线程安全又不牺牲读性能的容器，往往是架构设计的关键。而 CopyOnWriteArrayList 的读写分离机制，可以说天生就是为“高频读、极低频写”这类场景量身定做的。它的核心逻辑非常清晰：读操作完全不加锁，直接访问数据快照；写操作则通过加锁和复制副本来保证一致性。这样一来，无需复杂的额外设计，就能轻松实现无锁化的高吞吐量读访问。

读操作全程无锁，直接访问 volatile 数组快照

它的底层实现依赖于一个被 volatile 关键字修饰的 Object[] 数组来存储数据。所有读方法——无论是 get、size 还是 contains 和 iterator()——都只是简单地调用 getArray() 来获取当前数组的引用，然后直接进行读取。整个过程你看不到任何 synchronized、lock 或者 CAS 自旋的影子。这得益于 volatile 保证了引用更新的即时可见性，任何线程在读取时，拿到的都是某个确定时间点的完整数据快照。

• 举个例子，list.get(0) 本质上就是一次 (E) array[0] 的内存访问，时间复杂度是 O(1)，效率极高。
• 迭代器在构造时，会立即拷贝当前的数组引用，之后的遍历操作就与后续的任何写操作彻底隔离了。
• 即使此时有写线程正在后台复制数组、准备替换引用，读线程依然能稳定地访问旧数组，既不会阻塞卡顿，也不需要重试。

写操作独占加锁 + 全量复制，但低频时不构成瓶颈

那么写操作是如何进行的呢？所有写方法，包括 add、remove 和 set，都会统一先获取一把 ReentrantLock 锁。这确保了同一时刻最多只有一个写线程在执行。加锁之后，它会先将原数组完整复制一份（使用 Arrays.copyOf），然后在副本上进行修改，最后通过一次 volatile 写操作，将 array 引用指向全新的数组。

• 一次写操作的总耗时大致等于：数组长度 × 元素拷贝开销 + 锁竞争等待时间。
• 如果列表长度长期稳定在几百或几千的量级，并且写入频率极低，比如每分钟才发生一次，那么这点复制开销几乎可以忽略不计。
• 这里的关键在于：整个写操作过程中，完全不影响任何并发的读操作。系统的读吞吐量不会因此下降，响应时间也不会产生抖动。

迭代器天然支持弱一致性遍历，避免 ConcurrentModificationException

这是它另一个非常实用的特性。调用 iterator() 所返回的迭代器，是基于创建那一刻的数组快照。因此，整个遍历过程都独立于之后发生的任何修改。这对于日志轮转、配置广播、监听器通知等需要安全并发读取的场景来说，简直是福音。

• 你在遍历时，其他线程即使调用了 add("new")，当前迭代器也“看”不到这个新元素，并且不会抛出任何异常。
• 需要注意的是，迭代器本身不支持 remove() 操作，调用它会直接抛出 UnsupportedOperationException，这反而杜绝了在遍历时误修改数据源的可能。
• 所以，它特别适合那些“只读消费”型的逻辑，比如监控线程定时转储当前全部的监听器状态，或者推送服务批量拉取活跃客户端列表。

典型落地示例：配置项缓存容器

让我们设想一个典型的应用场景：系统加载了一份全局的功能开关配置（例如 feature flags），这些配置在服务启动后极少发生变更。

• 初始化：CopyOnWriteArrayList flags = new CopyOnWriteArrayList(List.of("login-v2", "pay-async"));
• 高频读（每毫秒可能发生多次）：业务代码中频繁执行 if (flags.contains("pay-async")) { ... }。由于完全无锁、无竞争，也没有额外的GC压力，性能极高。
• 极低频写（由运维后台触发）：当需要新增一个开关时，执行 flags.add("report-realtime")。这个过程会加锁并复制一次数组，在数据量不大时能在毫秒级完成。
• 在此期间，所有工作线程读取到的仍然是变更前的配置快照，直到下次读取时才会自然切换到新的数组引用，从而实现配置的无缝、平滑过渡。