错误的结论

在网上搜索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源码截图

面试官:HashMap 中 modCount 变量有什么作用?大部分人都理解错了。。_迭代

2.JDK6源码截图

面试官:HashMap 中 modCount 变量有什么作用?大部分人都理解错了。。_迭代器_02

3.JDK7源码截图

面试官:HashMap 中 modCount 变量有什么作用?大部分人都理解错了。。_迭代器_03

4.JDK8源码截图

面试官:HashMap 中 modCount 变量有什么作用?大部分人都理解错了。。_迭代_04

我的思考

难道到了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​​异常的描述,我有以下看法:

  1. 该异常不单单会在多线程情况下发生;
  2. 在单线程情况下也可能发生,就是在有使用有fail-fast机制的迭代器遍历集合时,有修改集合的操作也会抛出此异常;
  3. HashMap中的modCount是为了结论2而设计的。