博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
ConcurrentModifcationException详解
阅读量:3921 次
发布时间:2019-05-23

本文共 2310 字,大约阅读时间需要 7 分钟。

本文主要讲解为什么会产生ConcurrentModifcationException,以及底层代码分析,并且避免产生该异常的方法。

再讲ConcurrentModifcationException的时候,非常必要的说道集合的迭代器,不同的迭代器会产生不同的效果。

Java中的迭代器

快速失败(fail—fast)

在用迭代器遍历一个集合对象时,如果遍历过程中对集合对象的内容进行了修改(增加、删除、修改),则会抛出ConcurrentModificationException

执行该操作的迭代器称为快速失败迭代器,因为迭代器很快就完全失败,而不会冒着在将来某个时间任意发生不确定行为的风险。迭代器的快速失败行为无法得到保证,因为一般来说,不可能对是否出现不同步并发修改做出任何硬性保证。快速失败操作会尽最大努力抛出ConcurrentModificationException。

应用场景

场景:java.util包下的集合类都是快速失败的,不能在多线程下发生并发修改(迭代过程中被修改)。不光是多线程,在单线程时也可能发生该异常。

多线程下发生该异常,代码如下:

在这里插入图片描述
在遍历整个list集合的时候,向里边添加元素,因为改变了list的结构,modCount会发生改变,故发生该异常。
在这里插入图片描述
单线程下发生该异常:
在这里插入图片描述
因为在for循环遍历时候删除元素,同样改变了list的结构导致modCount发生改变,所以会抛出异常。
在这里插入图片描述

原理

迭代器在遍历时直接访问集合中的内容,并且在遍历过程中使用一个modCount变量。集合在被遍历期间如果内容发生变化,就会改变modCount的值。每当迭代器使用next()遍历下一个元素之前,都会检测modCount变量是否为expectedmodCount值,是的话就返回遍历;否则抛出异常,终止遍历。

例如我们查看ArrayList的关于iterator()方法,是new了一个Itr对象。

在这里插入图片描述
那我们进来看看这是一个什么对象呢?这是AbstractList类的一个成员,查看他的next方法。在这里插入图片描述
在next方法内部查看是否还有剩余元素的时候,会首先调用checkForComodification()方法,那么这个方法是干什么的呢?
在这里插入图片描述
这个方法很简单,就是查看modCount变量是否的等于expectedModcount,如果这个值和期待的不相同的话就会抛出ConcurrentModificationException。

那么这个modCount是干什么的呢?

还是查看AbstractList中的注释:

在这里插入图片描述

对于英语0级的我们,我还是去百度翻一下吧。

此列表在结构上被修改的次数。结构修改是那些改变列表大小的修改,或者以其他方式干扰列表,使得正在进行的迭代可能产生不正确的结果。此字段由迭代器和列表迭代器方法返回的迭代器和列表迭代器实现使用。如果此字段的值意外更改,则迭代器(或列表迭代器)将抛出ConcurrentModificationException以响应下一个、删除、上一个、设置或添加操作。这提供了快速失败的行为,而不是迭代过程中并发修改时的不确定行为。子类使用此字段是可选的。如果子类希望提供快速失败的迭代器(和列表迭代器),那么它只需在其add(int,E)和remove(int)方法(以及它重写的导致列表结构修改的任何其他方法)中增加这个字段。对add(int,E)或remove(int)的单个调用必须向该字段添加不超过一个,否则迭代器(和列表迭代器)将抛出虚假的ConcurrentModificationExceptions。如果实现不希望提供失败快速迭代器,则可以忽略此字段。

也就是说在对list的结构进行改变(list大小发生改变)的时候,modCount就会发生改变,旨在记录改变的次数。

所以综上所述:在对java.util包下的集合类进行并发修改的时候,一边改变数组的结构,一遍进行遍历,由于modCount发生了改变,所以就会跑异常。

安全失败(fail—safe)

采用安全-失败机制的集合容器,在遍历时不是直接在集合内容上访问的,而是先复制原有集合内容,在拷贝的集合上进行遍历

场景

java.util.concurrent包下的容器都是安全失败,可以在多线程或者单线程下并发使用,并发修改。

如多线程下:

在这里插入图片描述
在单线程下:
在这里插入图片描述

原理

由于迭代时是对原集合的拷贝进行遍历,所以在遍历过程中对原集合所作的修改并不能被迭代器检测到,所以不会触发Concurrent Modification Exception。

同样地,迭代器并不能访问到修改后的内容,即:迭代器遍历的是开始遍历那一刻拿到的集合拷贝,在遍历期间原集合发生的修改迭代器是不知道的。

众所周知,使用java.util.concurrent包下的集合类比如对应ArrayList的CopyOnWriteArrayList类就可以避免该异常的出现,那么是什么原理呢?

让我们来看看他的源码,来到iterator()方法:

在这里插入图片描述
这个方法调用的是COWIterator对象来完成遍历,并且把当前的list也就是底层存储数据的数组数据,和要返回的元素的索引传过来。来到COWIterator类的next()方法。
在这里插入图片描述
看到上边的注释了吧,unchecked就是不用检查,直接遍历,所以也就不会产生这个异常了。

这是因为他遍历的是拷贝的数据快照,所以并不需要考虑并发修改的问题。

但是也有一个缺点:就是在遍历的时候他为了避免产生并发修改异常,所以拷贝出一份快照用于遍历,在遍历期间修改(添加,修改,删除)的数据遍历不到。

转载地址:http://hmqrn.baihongyu.com/

你可能感兴趣的文章
.NET开源5年了,这些宝藏你还没get?
查看>>
【日常排雷】 .Net core 生产环境appsetting读取失败
查看>>
从内存中释放Selenium chromedriver.exe
查看>>
如何在 C# 中使用 MSMQ
查看>>
小试elsa
查看>>
巧用 Lazy 解决.NET Core中的循环依赖关系
查看>>
微前端架构在容器平台的应用
查看>>
C# 中的 null 包容运算符 “!” —— 概念、由来、用法和注意事项
查看>>
仓储模式到底是不是反模式?
查看>>
ABP vNext分布式事件总线RabbitMQ注意事项
查看>>
【One by One系列】IdentityServer4(一)OAuth2.0与OpenID Connect 1.0
查看>>
为什么人和人的差距这么大?
查看>>
ML.NET 推荐引擎中一类矩阵因子分解的缺陷
查看>>
微软2020开源回顾:止不住的挨骂,停不下的贡献
查看>>
说说 RabbiMQ 的应答模式
查看>>
OpenTelemetry - 云原生下可观测性的新标准
查看>>
使用 ML.NET 实现峰值检测来排查异常
查看>>
通过 .NET NativeAOT 实现用户体验升级
查看>>
如何友好的处理 WebApi 中抛出的错误
查看>>
因MemoryCache闹了个笑话
查看>>