concurrenthashmap迭代器非fail-safe而是弱一致性，不抛concurrentmodificationexception但不保证看到所有修改；它用分段锁+cas+volatile实现线程安全，无modcount机制，设计取舍为高吞吐而非强一致性。
ConcurrentHashMap 没有“安全失败”（fail-safe）机制，它用的是**分段锁 + CAS + volatile + 不可变辅助结构**来实现线程安全，和 CopyOnWriteArrayList 那种靠复制实现的真正 fail-safe 完全不是一回事。混淆这点会导致对并发行为的严重误判。
为什么 ConcurrentHashMap 的迭代器不是 fail-safe
它的 entrySet().iterator()、keySet().iterator() 等返回的迭代器属于“弱一致性”（weakly consistent），不抛 ConcurrentModificationException，但也不保证看到所有已提交的修改——这常被误认为是 fail-safe，其实只是设计取舍：
- 迭代过程不加锁，不阻塞写操作，也不阻塞其他迭代器
- 可能跳过正在被插入的节点（因链表/红黑树结构变更未完全可见）
- 可能重复遍历某些节点（如扩容时某桶被迁移两次）
- 不会因结构修改而中断或抛异常，但结果不满足“快照语义”
ConcurrentHashMap 如何避免 CME 异常
它根本没用 modCount 这套检测逻辑。JDK 8+ 的 ConcurrentHashMap 完全移除了类似 ArrayList 的修改计数机制：
- 每个
Node的val和next字段都是volatile，保证可见性而非原子性 - 插入/删除通过
Unsafe.compareAndSwapObject+ 自旋重试完成，失败不抛异常而是重试 - 扩容时使用
transferIndex和sizeCtl协调多线程协作，不依赖全局状态校验 - 迭代器只读取当前桶的头节点，然后顺着
next向下遍历，不检查“中途是否被改过”
想用真正的 fail-safe？选错工具了
如果你需要迭代时绝对不漏、不重、不抛异常，且能反映某一时刻完整快照，ConcurrentHashMap 不满足。此时应考虑：
-
CopyOnWriteArrayList：适合读多写极少、迭代频繁的场景，但写操作代价高 - 手动加锁 +
new HashMap(map)创建快照：可控但需权衡锁粒度与一致性窗口 - JDK 17+ 的
ThreadLocalRandom.current().nextLong()配合不可变容器（如ImmutableMap）做无锁快照生成
别把“不抛 CME”等同于“安全失败”——前者是放弃检测，后者是主动保障语义。ConcurrentHashMap 的设计哲学是吞吐优先，一致性让步于性能，这点在高并发写入+迭代混用时尤其明显。
