抛ConcurrentModificationException原因的深究以及解决方案 (原创,申请推荐)

Question

原文博客地址: http://blog.csdn.net/izard999/article/details/6708738
绝对原创, 转载请标明文章出处:http://blog.csdn.net/izard999/article/details/6708738大家应该都知道, 在java中, 在对一些集合迭代的过程中对集合进行一些修改的操作, 比如说add,remove之类的操作, 搞不好就会抛ConcurrentModificationException, 这一点在API文档上也有说的!   在迭代时只可以用迭代器进行删除! 但是文档上只是说了删除,  其他操作也会引起ConcurrentModificationException,  这是为何呢.? 下面就跟着我一起探索源代码吧! 就以ArrayList为例!
当我在迭代ArrayList时, 首先获取ArrayList的迭代器ArrayList.iterator(), 接下来就是hasNext与next的使用,例如:List list = new ArrayList();
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
public boolean hasNext() {
            return cursor != size();
} public E next() {
            checkForComodification();
    try {
E next = get(cursor);
lastRet = cursor++;
return next;
    } catch (IndexOutOfBoundsException e) {
checkForComodification();
throw new NoSuchElementException();
    }
}
看next中调用的checkForComodification(), 在remove方法中也调用了checkForComodification()！接着checkForComodification()方法里面在做些什么事情！
final void checkForComodification() {
    if (modCount != expectedModCount)
throw new ConcurrentModificationException();
}
所以在迭代的过程中，hasNext()是不会抛出ConcurrentModificationException的， next和remove可能方法会抛！  抛异常的标准就是modCount != expectedModCount！继续跟踪这两个变量,在Itr类的成员变量里对expectedModCount初始化的赋值是int expectedModCount = modCount;那么这个modCount呢.? 这个是AbstractList中的一个protected的变量,  在对集合增删的操作中均对modCount做了修改,  因为这里是拿ArrayList为例, 所以直接看ArrayList中有没有覆盖父类的add.?   结果发现覆盖了public boolean add(E e) {
ensureCapacity(size + 1);  // Increments modCount!!
elementData[size++] = e;
return true;
    }public void ensureCapacity(int minCapacity) {
modCount++;
int oldCapacity = elementData.length;
if (minCapacity > oldCapacity) {
    Object oldData[] = elementData;
    int newCapacity = (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没有!所以大家以后如果遇到ConcurrentModificationException的话, 拿着我写的这个思路去举一反三, 静下心来找下源代码都是可以解决问题的!  

Answer 1

有点没全看明白，所以刚也看了下源码
简言之：
为什么会抛ConcurrentModificationException呢？
是因为public E next() {
  checkForComodification();
  ......
}final void checkForComodification() {
    if (modCount != expectedModCount)
    throw new ConcurrentModificationException();
}
即当modCount != expectedModCount时，执行next()就会抛出ConcurrentModificationException而什么时候会造成modCount != expectedModCount呢？ArrayList.add()方法，每执行一次都会modCount++(当然删除就是modCount--)，但不改变expectedModCount的值。expectedModCount的值是在构建迭代的时候初始为expectedModCount=modCount的。这就是楼主说的在构建迭代器之后，再使用ArrayList.add()方法就造成了modCount != expectedModCount所以构建迭代器后，用迭代器来add和remove就没有问题。因为它会在改变modCount的值之后，又把值赋给了expectedModCount，从而保证modCount=expectedModCount

Answer 2

是的,expectedModCount是迭代器里的变量, 获得迭代器的时候就会赋值, 而modCount是List中的变量, 会随着集合修改而变的

Answer 3

哈哈 读了 HashMap  和 ConcurrentHashMap 源码以后 就清楚啦

Answer 4

我一般习惯用 synchronized(obj)来解决集合同步的问题

Answer 5

貌似不用iterator而直接使用lists.get(i)和lists.remove(i)不会报错呢

Answer 6

遍历set和map的时候，我才用iterator。
list到是没怎么用过。
以前处理这个错都是在改变集合扣，重新获取iterator
如：
for(Iterator it...)
{
  map.remove(key);
  
  it=map.keySet.iterator();
}

Answer 7

arraylist不是线程安全的，当然会出这个错。在多线程环境还是用Vector吧

Answer 8

抛异常是Iterator中的next和remove抛异常,  不用迭代器很显然不会抛异常啊

Answer 9

借楼主帖，问个问题，Struts2 请求 返回 页面%<@{number1} >
跟%<%{number1},'%{@path}'>
是什么意思？

Answer 10

、
补充上面，请问这样的写法跟以前有什么不同？ "#request.number" 这中的不同？

Answer 11

有探究精神，但是本来就是便利List,来获得结果的，为啥在遍历中又进行其他操作呢

Answer 12

分析的不错，把ArrayList换成CopyOnWriteArrayList就不会出现这个异常了

Answer 13

我记得java数据结构那本书有分析过源码，迭代器和那个集合本身都有一个计数器，一旦发现不相等就会抛异常