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等集合类都存在上述问题，请大家在编码时谨慎使用。