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 出现在最不好复现的时间点。
