copyonwritearraylist遍历时不用加锁因其迭代器基于底层数组的不可变快照，写操作通过原子替换引用更新数组，读写互不阻塞；但写操作本身使用reentrantlock，仅读操作无锁。
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 不同），但也不会影响当前迭代器——因为迭代器用的是旧副本。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
真正容易踩坑的地方是语义误解：
-
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() 也不影响本次循环
}
}
}</eventlistener>
注意：如果 onEvent() 内部又调用了 addListener() 或 removeListener()，那只是影响下一次遍历的快照，当前循环看到的仍是调用 fireEvent() 时的完整列表。
真正难处理的是「遍历中依赖写操作结果」的逻辑——这种需求本身就和 CopyOnWriteArrayList 的设计相悖，得换结构，比如用 ConcurrentLinkedQueue 配合重试，或者加外部协调机制。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
