CopyOnWriteArrayList写操作不阻塞读，因每次修改都新建数组复制内容，读操作持老数组引用且无锁；但写开销大、迭代器不可见新元素、多方法组合非原子。
CopyOnWriteArrayList 写操作为什么不会阻塞读？
因为每次 add、set、remove 都会新建数组，把原数组内容复制过去再修改，老数组继续供正在执行的 get 或遍历使用。读操作全程无锁，也不怕并发修改异常。
但代价是：写操作要复制整个数组，内存开销大，且新写入的元素对「已开始但未结束」的迭代器不可见——这是它最常被误用的点。
- 适合读多写少场景，比如监听器列表、配置项快照
- 写频繁时（如每秒数百次
add），GC 压力明显上升，可能触发频繁 Young GC -
Iterator是快照式遍历，调用iterator()后，后续的add对该迭代器完全不可见
遍历时修改会抛 ConcurrentModificationException 吗？
不会。这是 CopyOnWriteArrayList 和 ArrayList 的关键区别之一——它的 Iterator 不检查 modCount，底层直接持有一份创建时的数组引用。
但要注意：它「不报错」不等于「行为符合预期」。常见陷阱是以为边遍历边 add 能让下一轮循环看到新元素，实际根本看不到。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 错误写法：
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 很拿手，后者它经常默默给你埋雷。
