转载出处:http://blog.csdn.net/izard999/article/details/6708738
大家应该都知道, 在Java中, 在对一些集合迭代的过程中对集合进行一些修改的操作, 比如说add,remove之类的操作, 搞不好就会抛ConcurrentModificationException, 这一点在API文档上也有说的! 在迭代时只可以用迭代器进行删除!
但是文档上只是说了删除, 其他操作也会引起ConcurrentModificationException, 这是为何呢.? 下面就跟着我一起探索源代码吧! 就以ArrayList为例!
当我在迭代ArrayList时, 首先获取ArrayList的迭代器ArrayList.iterator(), 接下来就是hasNext与next的使用,例如:
```
List list =newArrayList();
list.add("a");
list.add("b");
for(Iterator it = list.iterator(); it.hasNext;) {
Object o = it.next();
}
```
但是如果你在迭代的过程中不是用迭代器对集合进行修改, 而是用直接操作集合, 例如在迭代中: list.add(c);
此时你就非常有可能会惨兮兮了, 为什么只是有可能而非绝对呢? 下面接着分析
跟进ArrayList的源码看, 搜索iterator()方法看其获得的迭代器, 发现没有! 于是追其父类 AbstractList, iterator()方法返回new Itr()!
查看Itr中的两个重要的方法: hasNext与next
[java]view plaincopy
publicbooleanhasNext() {
returncursor != size();
}
publicE next() {
checkForComodification();
try{
E next = get(cursor);
lastRet = cursor++;
returnnext;
}catch(IndexOutOfBoundsException e) {
checkForComodification();
thrownewNoSuchElementException();
}
}
看next中调用的checkForComodification(), 在remove方法中也调用了checkForComodification()！接着checkForComodification()方法里面在做些什么事情！
[java]view plaincopy
finalvoidcheckForComodification() {
if(modCount != expectedModCount)
thrownewConcurrentModificationException();
}
所以在迭代的过程中，hasNext()是不会抛出ConcurrentModificationException的， next和remove可能方法会抛！ 抛异常的标准就是modCount != expectedModCount！继续跟踪这两个变量,在Itr类的成员变量里对expectedModCount初始化的赋值是int expectedModCount = modCount;
那么这个modCount呢.? 这个是AbstractList中的一个protected的变量, 在对集合增删的操作中均对modCount做了修改, 因为这里是拿ArrayList为例, 所以直接看ArrayList中有没有覆盖父类的add.? 结果发现覆盖了
[java]view plaincopy
publicbooleanadd(E e) {
ensureCapacity(size +1);// Increments modCount!!
elementData[size++] = e;
returntrue;
}
publicvoidensureCapacity(intminCapacity) {
modCount++;
intoldCapacity = elementData.length;
if(minCapacity > oldCapacity) {
Object oldData[] = elementData;
intnewCapacity = (oldCapacity *3)/2+1;
if(newCapacity < minCapacity)
newCapacity = minCapacity;
// minCapacity is usually close to size, so this is a win:
elementData = Arrays.copyOf(elementData, newCapacity);
}
}
remove方法中也做了modCount++, 当我获得迭代器之前, 无论对集合做了多少次添加删除操作, 都没有关系, 因为对expectedModCount赋值是在获取迭代器的时候初始化的!
也就是说, 如果我对集合添加删除一共操作了10次,此时modCount为10, 获取迭代器的时候expectedModCount也为10, 迭代期间会去checkForComodification()! 只要在next或者remove之前有对集合操作的动作导致modCount发生了改变, 就会抛那个并发修改异常!
为什么上面的可能会异常呢? 当modCount发生改变时, hasNext返回false的时候, 就不会执行循环里面的next/remove方法了, 也就不会抛异常了!
例如集合现在只有一个元素, 先Object o = it.next(),然后list.remove(o); 此时modCount变了, 但是下次hasNext返回false, next就不会执行,所以此时是不会抛异常的!
所以大家以后迭代集合的同时对集合操作一定要小心又小心, 不要以为没有抛异常就是没事!
而且在多线程并发的时候, 一个线程要迭代, 一个线程要对集合操作的时候, 抛不抛异常就要撞大运了!
google上对怎么解决ConcurrentModificationException的方案已经很多, 例如用Collections.synchronizedCollection() 去同步集合, 但是这样可能会影响效率, JDK5之后concurrent包里面有个CopyOnWriteArrayList, 这个集合迭代的时候可以对集合进行增删操作, 因为迭代器中没有checkForComodification!
但是好像没看到有分析为什么的, 所以就写了本文给大家分享下, 文中只拿ArrayList出来作为例子解释了为何会抛ConcurrentModificationException以及如何从原理上去避免!集合的种类众多, 各种迭代和集合操作的实现也不一样, 例如我看到SubList的add方法中就有checkForComodification,而ArrayList没有!
Ps:除了别人总结的，自己总结一下，以arraylist为例，arraylist继承的父类中包含了实现的的迭代器，并且提供了获取迭代器的方法，
获取父类实现迭代器
迭代器的remove方法
可以清楚的看到迭代器的方法会在每次remove以后把modCount给expectedModeCount,从而避免了在迭代器next方法中做check时候抛出异常，
迭代器next方法
check方法
但是list本身提供的remove中含有的fastremove并没有做这些校验，以及赋值，所以在剔除一个元素以后，下次迭代器执行next方法时候就会抛出异常，这也解释了为什么在list.remove（obj）立即break也不会抛出异常。
另外如果list中如果只有两个元素，无论用哪种方法都不会抛出异常，因为list.remove删除了一个元素以后，hasnext会判断1！=1，会返回false，不会再进入循环，所以会跳出。
hasnext方法
-------------------------------------------------------分割线-----------------------------------------------------------
第一次写总结，各种懵逼中，希望以后更多总结吧。加了个油
