concurrenthashmap迭代器不抛concurrentmodificationexception，因其采用弱一致性快照遍历而非modcount检测；foreach是并行分段扫描，iterator是单线程弱一致遍历；需原子复合操作时应手动分段扫描或用原子方法。
ConcurrentHashMap 迭代器为什么不会抛 ConcurrentModificationException
因为它的迭代器是弱一致性的，不依赖 modCount 机制做修改检测，而是基于创建瞬间的内部结构快照进行遍历。这和 HashMap 或 ArrayList 的 fail-fast 设计完全不同。
- 迭代开始时，
Traverser会按 Segment（JDK7）或 table 桶数组（JDK8+）分段扫描，每个段只读取当前可见的节点链/树 - 遍历时其他线程对同一桶的
put/remove不会影响当前迭代流程——新节点可能被跳过，已删除节点可能仍被访问到 - 没有全局锁、也不检查版本号，所以绝不会因并发修改而中断或抛出
ConcurrentModificationException
forEach(BiConsumer) 和 entrySet().iterator() 的行为差异在哪
两者都“能用”，但底层逻辑和适用场景完全不同：前者是并行分段扫描，后者是单线程弱一致性遍历。
-
forEach()底层调用Traverser并发分片处理，适合只读聚合（如统计、日志打印），但不能在 lambda 中调用computeIfAbsent、remove等写操作，否则可能触发IllegalStateException -
entrySet().iterator()返回的是传统迭代器，虽不抛异常，但遍历中若其他线程修改了正在访问的桶，该次迭代仍用旧引用，不会重试或刷新 - 二者都不保证看到最新状态；如果业务要求“必须看到所有刚插入的元素”，就得换方案——比如先
keySet().toArray()再逐个get，或改用外部同步
什么时候该放弃迭代器，改用 mappingCount() + 手动分段扫描
当你要在遍历中做原子性复合操作（比如“查 key → 删 key → 记录日志”），又不想锁整个 map 时，标准迭代器就力不从心了。
-
size()有误差、mappingCount()更准但仍是估算值，不能当判断依据；真正需要精确控制遍历粒度时，得自己按桶索引分段走 - JDK8+ 可用
newKeySet().spliterator()或直接操作table数组（不推荐），但更稳妥的是用forEach配合computeIfPresent或replaceAll这类原子方法 - 典型踩坑：用
for (Entry<k> e : map.entrySet())</k>做map.remove(e.getKey())—— 这不是线程安全的删除，只是删掉了当前线程看到的副本，别的线程可能还在用这个 key 做计算
computeIfAbsent 在并发遍历中重复初始化的真相
它不是 bug，是设计使然：两次 get + 一次加锁内检查之间存在竞态窗口，多个线程可能同时进入 mappingFunction。
- 现象：
map.computeIfAbsent(key, k -> new ExpensiveObject(k))可能创建多个实例，尤其在高并发首次访问时 - 原因：第一次
get未命中 → 加锁 → 再次get仍未命中 → 执行函数 → 插入；但两个线程几乎同时通过第一次检查，就会各自执行构造逻辑 - 解法不是加锁，而是让 mappingFunction 幂等：比如返回
FutureTask缓存（JDK9+ 推荐）、或用putIfAbsent+ 初始化后置校验
Collections.synchronizedMap 那种全局锁模式——这不是 ConcurrentHashMap 的设计目标。 
