CopyOnWriteArrayList核心用途是多线程下边读边写不抛ConcurrentModificationException，靠读写分离和写时复制实现遍历安全，但遍历看不到新写入元素，适用于读多写少场景。
遍历时修改不会抛 ConcurrentModificationException
这是 CopyOnWriteArrayList 最核心的用途：在多线程环境下边读边写，遍历过程完全不会因其他线程调用 add()、remove() 而中断。它靠的是「读写分离 + 写时复制」——每次写操作都新建数组并复制原内容，而迭代器始终持有一个快照（即创建时的数组引用），所以遍历看到的是旧数据，但不会出错。
常见错误现象：
直接用普通 ArrayList 在多线程中边 for-each 边 remove()，大概率触发 ConcurrentModificationException；换成 CopyOnWriteArrayList 后异常消失，但要注意——你删掉的元素，当前正在遍历的迭代器是看不到的。
- 适用于读多写少场景（比如监听器列表、配置白名单）
- 写操作开销大：每次
add()/remove()都要数组复制，时间复杂度 O(n) - 迭代器不支持
remove()（调用会抛UnsupportedOperationException）
iterator() 和 listIterator() 的行为差异
两者都返回只读快照视图，但语义略有不同：iterator() 是单向前向遍历，listIterator() 支持双向及索引定位。关键点在于——它们都**不反映后续写操作**，且都不允许通过迭代器修改集合。
使用场景举例：广播事件时遍历监听器列表，同时允许其他线程动态增删监听器，此时用 iterator() 最自然；若需从末尾反向处理（如清理资源），可用 listIterator(size())，但注意它仍基于构造时刻的数组。
立即学习“Java免费学习笔记（深入）”；
-
iterator()返回的Iterator不支持remove() -
listIterator()支持hasPrevious()/previous()，但同样禁止修改 - 所有迭代器的
size()、contains()等方法都作用于快照，不是实时状态
和 Collections.synchronizedList() 的关键区别
别误以为加了同步锁就等于安全遍历。Collections.synchronizedList(new ArrayList()) 仅保证每个方法原子性，但复合操作（如先 size() 再 get(i)）仍需手动同步；而遍历本身（for-each）本质是多次 get() + hasNext()，中间可能被其他线程写入打断，导致不一致或异常。
CopyOnWriteArrayList 把一致性保障下沉到数据结构内部，无需额外同步块。代价是内存占用翻倍（写时复制）、写延迟明显（新元素对当前遍历不可见）。
- 同步包装类适合需要强实时一致性的场景（如计数器、状态机）
-
CopyOnWriteArrayList适合「最终一致 + 遍历安全」优先的场景 - 二者都不能解决「读取后业务逻辑依赖旧值做写入」这类竞态，仍需更高层协调
实际代码里怎么避免踩坑
最常被忽略的是「写后立即读不到」这个特性。比如添加一个监听器后马上触发事件，却没被通知到——因为当前所有活跃迭代器还卡在旧快照上。
CopyOnWriteArrayListlisteners = new CopyOnWriteArrayList<>(); listeners.add(() -> System.out.println("A")); // 此时启动遍历 Thread t1 = new Thread(() -> { for (Runnable r : listeners) r.run(); // 输出 A }); // 另一线程新增 Thread t2 = new Thread(() -> listeners.add(() -> System.out.println("B"))); t1.start(); t2.start(); // B 不会被 t1 看到
- 不要依赖「刚 add 的元素马上能被遍历到」
- 避免在循环体内调用
add()或remove()（虽不报错，但新元素进不了本次遍历） - 如果需要强一致性读写，考虑
ReentrantReadWriteLock+ 普通ArrayList，而非盲目替换
它的安全是有条件的：安全在「不崩溃」，不在「实时」。理解这点，才能决定是不是真该用它。
