java.util.ConcurrentModificationException异常原因和解决方法

问题: 

在对集合迭代的时候,如果同时对其进行修改就会抛出java.util.ConcurrentModificationException异常,问题重现:

  
 

原因分析:

进入报错信息,定位LinkedHashMap719行,modCount != expectedModCount 抛异常。
modCount是HashMap类中的一个成员变量,表示对Map的修改次数,每次调用put()方法或者remove()方法就会对modCount进行加1操作;

expectedModCount:表示对Map修改次数的期望值,它的初始值为modCount。

 

对图一中的processes进行遍历时,modCount == expectedModCount;

1. 循环开始,由于modCount和expectedModCount相等,第一次循环获取了对象Entry
 
 
 
 
2. 进入循环体后,processes.remove(pid)方法实际上调用了父类HashMap的removeNode方法,最后++modCount,而expectedModCount不变
 
 
3. 继续循环,在nextNode()方法中,由于modCount != expectedModCount,报ConcurrentModificationException异常!
 

解决方案:

单线程:使用迭代器,通过迭代器进行删除。
为什么使用迭代器删除不会报错?
因为迭代器用了自己封装的remove方法,最后一步多了一个操作 expectedModCount = modCount
 
多线程:ConcurrentHasMap。
 

CopyOnWriteArrayList 介绍

(1)独占锁效率低:采用读写分离思想解决

既然独占锁的效率低下,那我们可以换一种方式,采用读写分离式的思想将读操作和写操作进行分开即可。

读操作不加锁,所有线程都不会阻塞。写操作加锁,线程会阻塞。

(2)写线程获取到锁,其他线程包括读线程阻塞

但是这时候又出现了另外一个问题了:写线程获取到锁之后,其他的读线程会陷入阻塞。

(3)复制思想:解决问题2

这咋办呢?我们可以再转化一下思想:

当我们往一个容器添加元素的时候,不直接往当前容器添加,而是先将当前容器进行 Copy,复制出一个新的容器,然后新的容器里添加元素,添加完元素之后,再将原容器的引用指向新的容器。

这时候会抛出来一个新的问题,也就是数据不一致的问题。如果写线程还没来得及写会内存,其他的线程就会读到了脏数据。

这就是CopyOnWriteArrayList 的思想和原理。就是拷贝一份写。所以使用条件也很局限,那就是在读多写少的情况下比较好。

源码分析(基于JDK1.8)

既然CopyOnWriteArrayList 主要是针对的读写操作,我们可以看看这两个方法的源码是如何实现的。

1、get方法

 

整个读的过程没有添加任何锁,就是普通的数组获取。

2、add方法

写操作添加了一个锁ReentrantLock,这个锁我们可以决定在什么时候加锁和释放更加灵活。保证了写操作线程安全。能够体现Copy的思想代码是 Arrays.copyOf(elements, len + 1);也就是数组复制了一份,最后setArray回去。

CopyOnWriteArrayList 总结

这个容器很简单,虽然是采用了读写分离的思想,但是却有很大不同,不同之处在于copy。

1、读写锁

读线程具有实时性,写线程会阻塞。解决了数据不一致的问题。但是读写锁依然会出现读线程阻塞等待的情况

2、CopyOnWriteArrayList

读线程具有实时性,写线程会阻塞。不能解决数据不一致的问题。但是CopyOnWriteArrayList 不会出现读线程阻塞等待的情况

 
List和Map等集合类都存在上述问题,请大家在编码时谨慎使用。
posted @ 2020-10-09 10:47  森林木马  阅读(14979)  评论(0编辑  收藏  举报