Java多线程安全使用CopyOnWriteArrayList

CopyOnWriteArrayList凭借“读不加锁、写时复制”的机制实现了高并发读场景下的卓越性能，特别适合监听器注册、配置快照等读多写少的用途；但它并非万能解药——写操作开销大、迭代器无法感知新增元素、多步操作非原子、数据仅保证最终一致而非强一致性，这些特性极易被误用，导致逻辑隐晦失效；真正关键的不是能否避免崩溃，而是能否确保业务结果正确，因此必须清醒判断：你究竟需要的是线程安全的表象，还是数据行为与预期严格一致的实质。

CopyOnWriteArrayList 写操作为什么不会阻塞读？

因为每次 add、set、remove 都会新建数组，把原数组内容复制过去再修改，老数组继续供正在执行的 get 或遍历使用。读操作全程无锁，也不怕并发修改异常。

但代价是：写操作要复制整个数组，内存开销大，且新写入的元素对「已开始但未结束」的迭代器不可见——这是它最常被误用的点。

• 适合读多写少场景，比如监听器列表、配置项快照
• 写频繁时（如每秒数百次 add），GC 压力明显上升，可能触发频繁 Young GC
• Iterator 是快照式遍历，调用 iterator() 后，后续的 add 对该迭代器完全不可见

遍历时修改会抛 ConcurrentModificationException 吗？

不会。这是 CopyOnWriteArrayList 和 ArrayList 的关键区别之一——它的 Iterator 不检查 modCount，底层直接持有一份创建时的数组引用。

但要注意：它「不报错」不等于「行为符合预期」。常见陷阱是以为边遍历边 add 能让下一轮循环看到新元素，实际根本看不到。

• 错误写法：

  for (String s : list) { if (s.equals("a")) list.add("b"); }

  —— "b" 在本次循环中绝不会被访问到
• 正确思路：先收集要加的元素，遍历完再批量 addAll
• 如果真需要「实时可见」，得换 ConcurrentLinkedQueue 或加显式锁，而不是硬用 CopyOnWriteArrayList

和 Collections.synchronizedList 有啥本质区别？

根本不在「是否线程安全」，而在于「读写冲突怎么处理」：Collections.synchronizedList 读写都走同一把锁，读多时容易卡住；CopyOnWriteArrayList 读不加锁、写加锁但只锁复制过程，读性能高得多。

• Collections.synchronizedList(new ArrayList()) 的 iterator() 仍需手动同步，否则可能抛 ConcurrentModificationException
• CopyOnWriteArrayList 的 size()、contains() 等方法返回的是「调用时刻」的快照值，可能和下一毫秒的实际情况不一致
• 如果业务依赖强一致性（比如库存扣减），它根本不适用——它天生是最终一致的

哪些操作不是原子的？容易被忽略的非原子组合

CopyOnWriteArrayList 单个方法是线程安全的，但多个方法连用就不是了。最典型的是「检查后执行」模式：

• if (!list.contains(x)) list.add(x); —— 两步之间可能有其他线程插入相同 x，导致重复
• String first = list.get(0); list.remove(0); —— 中间可能被其他线程清空，remove(0) 抛 IndexOutOfBoundsException
• 没有类似 ConcurrentHashMap.computeIfAbsent 的原子复合操作，这类逻辑必须自己加锁或改用其他结构

真正难的从来不是「用对类」，而是判断清楚：你到底要的是「不崩溃」，还是「结果正确」。前者 CopyOnWriteArrayList 很拿手，后者它经常默默给你埋雷。

今天关于《Java多线程安全使用CopyOnWriteArrayList》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！