起源：blog.csdn.net/dabusiGin/article/details/105483426
谬误的论断
在网上搜寻 HashMap 中变量 modCount 的作用时，大部分的解释都是这样：
Fail-Fast 机制
咱们晓得 java.util.HashMap 不是线程平安的，因而如果在应用迭代器的过程中有其余线程批改了 map，那么将抛出 ConcurrentModificationException，这就是所谓fail-fast 策略。
这一策略在源码中的实现是通过 modCount 域，modCount 顾名思义就是批改次数，对 HashMap 内容的批改都将减少这个值，那么在迭代器初始化过程中会将这个值赋给迭代器的 expectedModCount。在迭代过程中，判断 modCount 跟 expectedModCount 是否相等，如果不相等就示意曾经有其余线程批改了 Map：留神到 modCount 申明为 volatile，保障线程之间批改的可见性。
这个解释有放在 JDK5 和 JDK6 的时候，兴许是正确的，因为在 JDK5 和 JDK6 中变量 modCount 的确申明为 volatile。但在 JDK7 和 JDK8 中，曾经没有这样申明了！！！！！
上面是 JDK5、JDK6、JDK7 和 JDK8 的源码：
1.JDK5 源码截图
2.JDK6 源码截图
3.JDK7 源码截图
4.JDK8 源码截图
我的思考
难道到了 JDK7 和 JDK8 中就不须要应用 modCount 变量，避免应用迭代器的过程中有其余线程批改了 map？？？？？
我的思考是这样的：留神看变量 modCount 的正文中让咱们 See ConcurrentModificationException，那么咱们就找到 ConcurrentModificationException 异样，在该异样的正文中，有这样一段形容。
Note that this exception does not always indicate that an object has
been concurrently modified by a <i>different</i> thread. If a single
thread issues a sequence of method invocations that violates the
contract of an object, the object may throw this exception. For
example, if a thread modifies a collection directly while it is
iterating over the collection with a fail-fast iterator, the iterator
will throw this exception.大抵翻译如下：
请留神，此异样并不总是示意对象已被其余线程同时批改。如果单个线程收回一系列违反对象约定的办法调用，则该对象可能会抛出此异样。例如，如果线程应用有 fail-fast 机制的迭代器在汇合上迭代时批改了汇合，迭代器将抛出此异样。
通过这段对 ConcurrentModificationException 异样的形容，我有以下认识：
- 该异样不单单会在多线程状况下产生；
- 在单线程状况下也可能产生，就是在有应用有 fail-fast 机制的迭代器遍历汇合时，有批改汇合的操作也会抛出此异样；
- HashMap 中的 modCount 是为了论断 2 而设计的。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！