copyonwritearraylist.iterator() 返回不可变快照，遍历基于创建时的数组副本，无法感知后续增删改操作；不支持remove()/set()，调用抛unsupportedoperationexception；读无锁、写加锁并复制数组，适用于读多写少场景。
CopyOnWriteArrayList.iterator() 返回的是快照，不是实时视图
调用 iterator() 时，它立刻把当前底层数组的引用“冻结”下来，后续遍历全部基于这个不可变副本。这意味着：你加了新元素、删了旧元素、甚至清空了整个列表，只要迭代器已经创建，它就完全感知不到。
- 常见错误现象：
ConcurrentModificationException没有抛出，但业务逻辑误以为能“边读边看最新状态”，结果漏处理新增项 - 真实行为示例：主线程调用
list.iterator()后，子线程执行list.add("X")，主线程迭代器仍只输出旧数据 - 关键约束：该快照是
Object[]引用拷贝，不是深拷贝；若数组里存的是可变对象（如StringBuilder），其内部状态仍可能被其他线程修改
为什么迭代器不支持 remove() 和 set()
因为快照本身是只读视图——它持有的是某个历史时刻的数组引用，没有关联任何写锁或更新路径。调用这些方法没有意义，也不安全。
- 直接后果：所有结构性修改方法都会抛出
UnsupportedOperationException，不是设计疏漏，而是机制使然 - 替代做法：需要删除时，应改用
list.removeIf(...)或先收集待删元素再批量调用list.removeAll(...) - 注意陷阱：别在
for-each循环里写list.remove(...)，虽然语法合法，但会跳过下一个元素（因索引偏移）
写操作触发复制，但读操作全程无锁
add()、remove() 等写方法内部用 ReentrantLock 加锁，并调用 Arrays.copyOf() 创建新数组；而 get()、iterator()、size() 全部无锁，直接读取 volatile 数组引用。
- 性能影响：写操作时间复杂度是
O(n)，频繁增删会导致 GC 压力和 CPU 浪费，别把它当普通ArrayList用 - 适用场景：监听器列表、配置白名单、路由规则缓存等——读频次远高于写频次（比如 1000:1）
- 内存可见性保障：靠
volatile修饰的array字段，确保新数组引用对所有线程立即可见
快照机制不是银弹，要注意“陈旧性”带来的业务风险
弱一致性 ≠ 最终一致性。快照不会自动刷新，也不会通知你“数据已过期”。某些场景下，这种延迟会引发逻辑漏洞。
立即学习“Java免费学习笔记（深入）”；
- 典型踩坑点：用
CopyOnWriteArrayList存储实时告警事件，后台线程轮询迭代器消费，却因快照滞后导致重复消费或漏消费 - 判断依据：如果业务要求“看到最后一次写入后的状态”，就不能依赖迭代器，得改用
get(0)+size()手动控制索引，或换BlockingQueue - 容易被忽略的细节：即使只读线程很多，每个
iterator()都会持有一个数组引用，长期运行可能积累大量旧数组，需关注堆内存增长趋势
