围观：
错误的结论
在网上搜索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而设计的。
感谢阅读，希望对你有所帮助 :)
来源：blog.csdn.net/dabusiGin/article/details/105483426
与其在网上拼命找题？ 不如马上关注我们~
PS：因为公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。点“在看”支持我们吧！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/8626.html
