CopyOnWriteArrayList适合读多写少场景，通过写时复制实现线程安全，读无锁但写开销大、内存占用高，不支持迭代中删除，仅提供最终一致性。
CopyOnWriteArrayList 适合读多写少的并发场景
它内部通过“写时复制”实现线程安全，每次 add、remove 都会新建数组并复制全部元素，所以写操作开销大，但读操作完全无锁、不阻塞。典型适用场景包括：监听器列表（如 Swing 事件监听、Netty 的 ChannelHandler 管理）、配置项订阅者集合、白名单/黑名单缓存等——这些场景通常初始化后极少修改，但被高频遍历或迭代。
反例：如果每秒执行几十次 add 或 remove，尤其集合大小超过几百，会明显拖慢吞吐，并引发频繁 GC。
迭代过程不会抛出 ConcurrentModificationException
因为迭代器持有的是快照数组，即使其他线程正在修改列表，Iterator 仍能安全完成遍历。这点和 ArrayList + synchronized 或 Collections.synchronizedList 不同——后者在遍历时若发生结构变更，几乎必然触发 ConcurrentModificationException。
注意：Iterator.remove() 是无效操作，调用后会抛出 UnsupportedOperationException；它不支持边遍历边删除。
立即学习“Java免费学习笔记（深入）”；
- 遍历时需要过滤或删除？必须先收集待删元素，遍历结束后再调用
removeAll() - 不能依赖迭代器的实时性：你看到的永远是“开始迭代那一刻”的状态
不适用于需要强一致性或低延迟写入的场景
CopyOnWriteArrayList 的写操作不是原子的：从修改开始到新数组替换旧引用之间存在短暂窗口，且读线程可能读到旧版本。它提供的是最终一致性，而非实时一致性。
常见误用：
- 当作计数器或状态开关（如
isRunning = list.isEmpty()）——结果可能滞后 - 在实时风控逻辑中维护“当前活跃会话列表”，因写延迟导致误判
- 与
size()配合做条件判断（如if (list.size() > 0) list.get(0)），可能因中间被清空而抛IndexOutOfBoundsException
这类需求更适合 ConcurrentLinkedQueue、BlockingQueue 或显式加锁控制。
替代方案对比：什么时候该选别的容器？
不要只看“线程安全”四个字就默认选 CopyOnWriteArrayList。实际选型要看访问模式：
- 读多写少 + 迭代频繁 →
CopyOnWriteArrayList - 读写均衡 + 需要低延迟写入 →
ConcurrentHashMap（把索引当 key，或改用键值结构） - 高并发写 + 允许阻塞读 →
ReentrantLock包裹普通ArrayList（比 CopyOnWrite 更省内存） - 纯生产-消费模型 →
ArrayBlockingQueue或LinkedBlockingQueue
最常被忽略的一点：它的内存占用是普通 ArrayList 的两倍（写操作期间新旧数组共存），且老数组等待 GC 回收——在堆内存紧张或对象生命周期长的系统里，这点影响远超预期。
