concurrenthashmap迭代器不抛concurrentmodificationexception，因其根本未使用modcount校验机制，而是采用弱一致性设计：按桶顺序遍历volatile数组，跳过扩容中桶，不阻塞写操作，也不保证看到最新或全部修改。
ConcurrentHashMap 的迭代器不抛 ConcurrentModificationException，不是靠“保证一致性”，而是主动放弃强一致性，用弱一致性换取高并发性能。它不检测、不阻塞、不回滚，只基于某个时间点的局部状态安全遍历。
弱一致性不是 bug，是设计取舍
与 HashMap、ArrayList 等 fail-fast 集合不同，ConcurrentHashMap 的迭代器从不检查 modCount 变更。它的目标很明确：让读操作（包括遍历）尽量快、不干扰写操作，哪怕看到的数据不是最新、不全、甚至略重复。
- 迭代开始时，它不冻结整个表，而是按桶（bin）顺序逐段访问当前可见的节点
- 写线程在插入、删除或扩容时，完全不受迭代器影响，也不需要等待迭代完成
- 没有全局版本号或快照拷贝机制，但每个桶的链表/红黑树头节点更新都通过 CAS 或 synchronized 保障局部可见性
底层如何实现“不抛异常”的遍历
以 JDK 1.8+ 为例，keySet().iterator() 返回的是 KeyIterator，其核心逻辑依赖于：
Javascript Sdk
下载
用于 inference.sh 的 JavaScript/TypeScript SDK，可运行 AI 应用、构建代理、集成 150+ 模型。包名：@inferencesh/sdk（npm install），完整 TypeScript 支持。
-
分段遍历 + volatile 桶数组：迭代器按索引顺序扫描
Node[] table，每个桶引用是 volatile 的，能读到已发布的节点结构 -
跳过空桶、跳过未初始化桶：若某桶正在扩容中（指向
ForwardingNode），迭代器会尝试跳转到新表对应位置；若新表尚未就绪，则略过该桶 -
不追踪链表中间变更：一旦进入某个桶的链表，就顺着
next指针往下走——即使另一线程刚把一个新节点插入到中间，只要没改变当前已遍历节点的next，就不会被看到
为什么不会抛 ConcurrentModificationException
因为它的迭代器类（如 KeyIterator）压根没有 expectedModCount 字段，也不在 next() 中校验任何修改计数器。
- fail-fast 是 HashMap 等非线程安全集合的防御性策略，用于快速暴露错误使用方式
- ConcurrentHashMap 默认场景就是多线程并发读写，抛异常反而违背设计初衷
- 它用文档明确告知：“迭代器返回的元素是某一时刻的弱一致性视图”，这是契约，不是缺陷
实际开发要注意什么
理解弱一致性后，关键不是“怎么避免问题”，而是“怎么适配这种行为”：
- 不要依赖遍历结果做原子性判断（比如“遍历完没找到就插入”——应改用
putIfAbsent） - 统计类操作（如
size()、mappingCount()）本身也弱一致，不要用于精确条件控制 - 若业务强依赖实时全量视图（极少数场景），需自行加锁或改用
Collection.synchronizedMap(new HashMap())，但会牺牲并发性能 - 推荐用
forEach、search、reduce等内置并行方法，它们内部已适配弱一致性语义
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
