来源：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中可能是正确的，因为变量modCount在JDK5和JDK6中确实声明为volatile。但是在JDK7和JDK8中，并没有这种说法！！！！！以下是JDK5、JDK6、JDK7、JDK8的源码：1.JDK5源码截图2.JDK6源码截图3.JDK7源码截图4.JDK8源码截图其他线程在iterator过程中是否修改了map？？？？？我的思路是这样的：注意在变量modCount的注释中看到ConcurrentModificationException，就会发现ConcurrentModificationException异常。在异常的注释中，有这样的描述。请注意，此异常并不总是表示对象已被不同线程并发修改。如果单线程发出一系列违反对象契约的方法调用，则该对象可能会抛出此异常。例如，如果线程在使用快速失败迭代器迭代集合时直接修改集合，则迭代器将抛出此异常。大致翻译如下：注意这个异常并不总是表示该对象已经被其他线程并发修改。如果单个线程发出一系列违反对象契约的方法调用，对象可能会抛出此异常。例如，如果线程在使用快速失败迭代器对其进行迭代时修改集合，则迭代器将抛出此异常。通过这个对ConcurrentModificationException异常的描述，我有以下看法：这个异常不仅仅出现在多线程的情况下；在单线程的情况下也可能出现，即当有一个具有fail-fast机制的迭代器遍历集合时，修改集合的操作也会抛出这个异常；HashMap中的modCount是为conclusion而设计的2.近期热点文章推荐：1.1,000+Java面试题及答案（2022最新版）2.厉害了！Java协程来了。..3.SpringBoot2.x教程，太全面了！4.不要用爆破爆满画面，试试装饰者模式，这才是优雅的方式！！5.《Java开发手册（嵩山版）》最新发布，赶快下载吧！感觉不错，别忘了点赞+转发！
