来源: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开发手册(嵩山版)》最新发布,速速下载!
觉得不错,别忘了随手点赞+转发哦!