起源：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 hasbeen concurrently modified by a <i>different</i> thread.  If a singlethread issues a sequence of method invocations that violates thecontract of an object, the object may throw this exception.  Forexample, if a thread modifies a collection directly while it isiterating over the collection with a fail-fast iterator, the iteratorwill throw this exception.

大抵翻译如下：

请留神，此异样并不总是示意对象已被其余线程同时批改。如果单个线程收回一系列违反对象约定的办法调用，则该对象可能会抛出此异样。例如，如果线程应用有fail-fast机制的迭代器在汇合上迭代时批改了汇合，迭代器将抛出此异样。

通过这段对ConcurrentModificationException异样的形容，我有以下认识：

  1. 该异样不单单会在多线程状况下产生；
  2. 在单线程状况下也可能产生，就是在有应用有fail-fast机制的迭代器遍历汇合时，有批改汇合的操作也会抛出此异样；
  3. HashMap中的modCount是为了论断2而设计的。

近期热文举荐：

1.1,000+ 道 Java面试题及答案整顿(2022最新版)

2.劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4.别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！

5.《Java开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞+转发哦！