concurrentmodificationexception 是运行时快照校验失败的快速失败机制，非并发控制协议；它不加锁、不阻塞、不保障一致性，仅提示可能出错。

ConcurrentModificationException 是一致性检测，不是一致性保障

快速失败（fail-fast）机制下的 ConcurrentModificationException 本质是「运行时快照校验失败」，不是并发控制协议。它只在迭代器调用 next() 或 hasNext() 时比对当前 modCount 和初始化时的 expectedModCount，一旦不等就抛异常——但这个检查本身不加锁、不阻塞、不回滚，也不保证两次遍历看到相同数据。

也就是说：它能帮你发现「可能出问题了」，但不能防止问题发生；它能终止当前遍历，但无法让集合回到修改前的状态。

• 单线程下误删元素触发异常，属于 bug 暴露，不是一致性保护
• 多线程下两个线程同时修改，modCount 可能被覆盖或绕过检测（比如增删抵消），异常不一定出现
• set(index, e) 不改变结构，不会触发异常，但确实改了内容——这说明「结构性修改」≠「所有修改」

安全失败（fail-safe）用空间换隔离，但一致性是「时间点快照」

CopyOnWriteArrayList 和 ConcurrentHashMap 的迭代器返回的是构造时刻的数组/哈希表快照，后续写操作不影响正在遍历的副本。这不是强一致性，而是「最终一致 + 时间切片隔离」。

关键点在于：你拿到的不是「最新值」，也不是「事务中值」，而是「我开始读那一刻的全部副本」。

• 遍历时新增元素，迭代器看不到；删除元素，迭代器仍会返回已删项（只要它在快照里）
• 多个线程同时遍历，各自拿到不同时间点的快照，彼此不可见——没有全局一致视图
• ConcurrentHashMap 的迭代器甚至不保证遍历完看到所有已存在键，因为分段重哈希可能移走桶

一致性权衡的本质是「读写语义边界」

快速失败默认假设「遍历期间集合不该变」，把一致性责任推给调用方：你要么同步块包住整个遍历+修改，要么先收集要删的 key 再批量删。安全失败则默认「读操作必须不阻塞、不失败」，把一致性代价转嫁给写操作和内存——每次写都要复制数组，且读到的数据天然滞后。

• 需要强一致性（如金融扣减、状态机迁移）？别用这两种，该上 ReentrantLock + 手动同步，或用 StampedLock 乐观读
• 读远多于写，且允许短暂陈旧（如监听器通知、配置列表轮询）？CopyOnWriteArrayList 合理
• 既要高并发读写，又要近实时一致性？ConcurrentHashMap 更合适，但得接受其迭代器不保证原子快照

最容易被忽略的坑：混合使用导致隐性不一致

在同一个业务逻辑里混用 ArrayList 和 CopyOnWriteArrayList，或者对 ConcurrentHashMap 做「先查后删」却没用 computeIfPresent，就会掉进一致性裂缝里。

• 用 ArrayList.iterator() 遍历时调 removeIf() —— 看似安全，实则仍是 fail-fast，因为 removeIf 内部还是走的 Iterator.remove()
• 对 CopyOnWriteArrayList 调用 iterator().remove() 会抛 UnsupportedOperationException，不是因为线程不安全，而是设计上禁用
• ConcurrentHashMap 的 keySet().iterator() 和 entrySet().iterator() 行为不完全等价，后者更可能漏掉刚插入的条目

一致性从来不是集合类自己“给”的，是你在读写模式、异常处理、迭代时机之间亲手画出来的边界。选错机制不会立刻崩，但会让 bug 出现在最不好复现的时间点。