Java 高并发列表：CopyOnWriteArrayList 遍历不加锁技巧

CopyOnWriteArrayList凭借“快照式迭代器”实现遍历全程无锁——每次遍历时自动复制底层数组的不可变副本，读写完全解耦，既不阻塞写操作，也不被写操作干扰，特别适合读多写少、频繁遍历且能容忍最终一致性的场景（如监听器列表、配置白名单）；但需警惕其写操作O(n)开销、GC压力、Iterator.remove()无效、contains()等方法隐式加锁等陷阱，真正理解“读无锁≠全无锁”，才能避免在高并发中误用。

CopyOnWriteArrayList 为什么遍历时不用加锁

因为它的迭代器是快照式的——每次调用 iterator() 或 listIterator() 时，都会复制当前底层数组的一个不可变副本，后续遍历操作全在这个副本上进行。写操作（如 add()、remove()）则另起新数组并原子替换引用，不影响正在遍历的旧副本。

这意味着：遍历永远不阻塞写，写也永远不阻塞遍历，自然不需要在遍历逻辑里加 synchronized 或显式锁。

但要注意：这种“无锁”只对读操作成立；写操作本身仍是加锁的（内部用 ReentrantLock），只是粒度被限制在写路径上。

什么时候该用 CopyOnWriteArrayList 而不是 ArrayList 或 ConcurrentHashMap

它适合「读多写少 + 遍历频繁 + 不要求强实时一致性」的场景。比如监听器列表、配置白名单、状态广播队列。

• 读操作（get()、size()、iterator()）完全无锁，性能接近 ArrayList
• 写操作（add()、remove()）开销大：要复制整个数组，时间复杂度 O(n)，且会触发 GC 压力
• 不支持 ConcurrentHashMap 那样的键值语义，也没有 computeIfAbsent 这类原子更新方法
• 遍历时看到的是「迭代器创建时刻」的快照，新增/删除的元素对本次遍历不可见

遍历时修改列表会怎样？常见陷阱有哪些

直接在遍历中调用 add() 或 remove() 不会抛 ConcurrentModificationException（这点和 ArrayList 不同），但也不会影响当前迭代器——因为迭代器用的是旧副本。

真正容易踩坑的地方是语义误解：

• Iterator.remove() 在 CopyOnWriteArrayList 中是**空操作**（什么也不做），返回 false；不能靠它删元素
• 想边遍历边过滤，不能用 iterator().remove()，得先收集待删元素，遍历完再批量调用 removeAll()
• 多个线程同时写，虽然安全，但无法保证写入顺序——因为每次写都基于「当时最新数组」，可能覆盖其他线程刚做的写
• contains()、indexOf() 等方法内部会加锁，不是无锁的，高并发下可能成瓶颈

一个典型安全用法示例

假设维护一个事件监听器列表，需要在事件分发时安全遍历：

public class EventDispatcher {
    private final CopyOnWriteArrayList<EventListener> listeners = new CopyOnWriteArrayList<>();

    public void addListener(EventListener l) {
        listeners.add(l); // 写操作，加锁但不阻塞读
    }

    public void fireEvent(Event e) {
        // 遍历自动获得快照，无需同步块
        for (EventListener l : listeners) {
            l.onEvent(e); // 即使 l 内部调用 removeListener() 也不影响本次循环
        }
    }
}

注意：如果 onEvent() 内部又调用了 addListener() 或 removeListener()，那只是影响下一次遍历的快照，当前循环看到的仍是调用 fireEvent() 时的完整列表。

真正难处理的是「遍历中依赖写操作结果」的逻辑——这种需求本身就和 CopyOnWriteArrayList 的设计相悖，得换结构，比如用 ConcurrentLinkedQueue 配合重试，或者加外部协调机制。

理论要掌握，实操不能落！以上关于《Java 高并发列表：CopyOnWriteArrayList 遍历不加锁技巧》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！