java hashmap的fail-fast机制通过modcount与expectedmodcount比对实现：迭代器初始化时绑定modcount值，每次nextnode()前校验二者是否一致，不等则抛concurrentmodificationexception；foreach采用遍历后校验；仅迭代器remove()可同步更新expectedmodcount以避免异常。
Java 中 HashMap 的 fail-fast 机制，在 HashIterator 节点遍历过程中，核心体现为每次调用 nextNode() 前强制校验结构一致性。它不是靠锁或同步来阻止并发修改，而是通过“快照比对 + 立即报错”暴露不一致，让问题在发生时就被捕获。
modCount 与 expectedModCount 的绑定发生在迭代器初始化时
当你调用 map.entrySet().iterator()，实际创建的是 EntryIterator（继承自 HashIterator）。此时构造函数会立即读取当前 HashMap 的 modCount，并赋值给迭代器自己的 expectedModCount 字段。这个动作只做一次，后续不再更新。
-
modCount是 volatile 修饰的，保证多线程下修改对所有线程可见 - 只要发生结构性修改（如 put、remove、clear、resize），
modCount就自增 - 非结构性操作（如仅修改已有 key 对应 value）不会触发
modCount变化
nextNode() 中的实时校验是 fail-fast 的执行点
每次调用 next()，最终都会进入 HashIterator.nextNode() 方法。该方法开头第一行就是校验逻辑：
- 检查当前
modCount是否仍等于当初记录的expectedModCount - 不等则立刻抛出
ConcurrentModificationException，遍历终止 - 这个校验发生在获取下一个节点前，不是事后补救，也不是延迟检测
forEach 方法的校验方式不同但目标一致
HashMap 的 forEach(BiConsumer) 也受 fail-fast 约束，但实现策略略有差异：
- 它在遍历开始前先缓存一份
modCount值（记为mc） - 完整遍历完所有桶和链表/红黑树节点后，再比对当前
modCount是否仍等于mc - 若不等，同样抛出异常，但此时遍历已结束——这是“事后校验”，但目的仍是拒绝容忍结构被中途篡改
迭代器自身的 remove() 是唯一被允许的修改方式
HashIterator 提供了 remove() 方法，它之所以不触发异常，是因为：
- 内部调用
removeNode()删除元素的同时，也会同步更新expectedModCount = modCount - 相当于“自己改，自己认账”，保持校验变量与真实状态一致
- 外部直接调用
map.remove()或其他写操作，则不会同步更新迭代器的expectedModCount，导致下次nextNode()校验失败
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
