一:什么时候出现？
当我们用迭代器循环list的时候，在其中用list的方法新增/删除元素，就会出现这个错误。
package com.sinitek.aml;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
public class ConcurrentModificationExceptionDemo {
public static void main(String[] args) {
List<String> arrayList = new ArrayList<>();
arrayList.add("a");
arrayList.add("b");
arrayList.add("c");
Iterator<String> iterator = arrayList.iterator();
while(iterator.hasNext()){
String tmp = iterator.next();
if ("a".equals(tmp)){
arrayList.remove(tmp);
}
}
}
}
二：为什么会出这个错误？
如上图所示，运行代码就会有这个错误，我们看一下堆栈。
Exception in thread "main" java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
at java.util.ArrayList$Itr.next(ArrayList.java:859)
at com.sinitek.aml.ConcurrentModificationExceptionDemo.main(ConcurrentModificationExceptionDemo.java:22)
可以看到，是在ArrayList里面的Itr内部类里的checkForModification()方法里，抛出的这个异常，我们看下源码。
final void checkForComodification() {
//如果修改的次数 和 预期修改的次数不一致，就会报错
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
}
可以看到，上面两个关键的值是：modCount和expectModCount,其中的modCount来自ArrayList的父类，AbstractList,有兴趣的可以看下上面的翻译，也说明了这个字段的作用，正是为了fail-fast(快速失败)设计的。
该值会在new出对象的时候，初始化为0；并且在每次的修改/删除操作时自增。
//arrayList的add方法，会先调用一次检查容量是否够的操作，我们可以看到，jdk专门在里面加了注释，会 Increments modCount, 增加modCount的值
public boolean add(E e) {
ensureCapacityInternal(size + 1); // Increments modCount!!
elementData[size++] = e;
return true;
}
//确保新增元素容量大小够用的方法
private void ensureExplicitCapacity(int minCapacity) {
modCount++; //首先先自增一次
// overflow-conscious code
if (minCapacity - elementData.length > 0) //判断最小需要的容量是否大于数组的长度(这里有个疑问，为什么一定相减然后判断是否>0,直接比较会有溢出的问题需要考虑么)
grow(minCapacity); //扩容
}
//删除方法，也会有modCount++的操作
public E remove(int index) {
rangeCheck(index);
modCount++;
E oldValue = elementData(index);
int numMoved = size - index - 1;
if (numMoved > 0)
System.arraycopy(elementData, index+1, elementData, index,
numMoved);
elementData[--size] = null; // clear to let GC do its work
return oldValue;
}
那我们看一下，expectedModCount时怎么变化的。
在ArrayList的内部类Itr(这个命名是不是有点随意了)里面，会看到expectedModCount是作为成员变量一起初始化的，所以我们在最开始的时候，调用list.iterator()方法的时候，就会初始化expectedModCount,将他变成和modCount一样的值。所以问题出在：
1. new ArrayList，新增后，modCount会有一个初始值0。
2. 调用iterator()方法后，会把expectedModCount的值初始化为modCount的值，此时，这两个值是一致的。
3. 如果在循环里，使用list对象新增/删除对象(本文最上面所作的操作)，modCount就会自增变化，而此时，expectedModCount却不会改变。
4. 调用iterator里面的next() -> checkForComodification()，判断modCount==expectModCount的时候，就会发现不一致，从而抛出这个异常。
三:怎么解决。
有两种方法。
-
- 使用Itr类中的remove方法移除，但是如果用的是从Iterable继承的iterator返回的Iterator是没有add()方法的接口的，如果需要add()，那么需要调用list专有的迭代器listInterator()方法返回的ListIterator().
- 不适用迭代器，使用原生的循环方式，这样就可以避免这个异常。(增强for只是一个语法糖(Syntactic Sugar)本质上还是使用了迭代器，也会有这个异常)。
四：为什么要定义这个异常？
凡事多问一个为什么，jdk为什么要怎么设计，很简单，其实从命名上就能看出来，当我们在循环的时候，无论是我们在迭代循环的时候(目前我们就是这种情况)，或者是其他的线程修改了这个(这个应该是jdk主要想解决的)，都会出现数据不一致的情况，所以需要这个异常，让你fail-fast,早点异常早点再次尝试等。
Q:为什么不在add()方法的时候，同时修改expectModCount,这样就他们一致了不就行了？
A:add()方法在调用的时候，有可能没有这个Itr这个对象，而且单单修改值是没有用的，需要把对应的迭代器内部保存数据的值也对应的修改，只修改expectModCount有点类似掩耳盗铃。
Q:那jdk可以新建一个重载方法，让itr对象当作参数，把他传进来，修改对应的保存数据的数组和对应的expectModCount，这样就能保证两个都一致了把。
A:确实，这种方法对于上文这种fail-fast确实适用，但是还有一种情况就是：可能修改list的线程和迭代的线程都不是同一个，所以根本就没有itr这个对象，也就无法修改这个值了。