为了回答你的问题，我写了一篇博客，我容易吗？（迭代器iterator遍历时候出现ConcurrentModificationException错误）

故事

为了在CSDN的问答社区获取几个基本，发现写的太多都可以作为一篇博文了，就顺道发了。
为了那几个原力分我容易吗？我容易吗？你还在这看我这博文，你忍心不点赞吗！！！

提问内容

---

题目

初始化一个LinkedList链表，然后采用迭代器向其添加元素

    LinkedList<Integer> li = new LinkedList<Integer>();
    li.add(0);
    for(int i = 1; i < 3; ++i){
        int size = li.size();
        Iterator<Integer> itr = li.iterator();
        for(int j = 0; j < size; ++j){
            li.add(itr.next()+1);
        }
    }

报错

在采用迭代器进行元素添加元素的时候出现了并发报错

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.117 sec <<< FAILURE!
test1(MainTest)  Time elapsed: 0.015 sec  <<< ERROR!
java.util.ConcurrentModificationException
	at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:966)
	at java.util.LinkedList$ListItr.next(LinkedList.java:888)
	at MainTest.test1(MainTest.java:17)

---

如何解决

将

Iterator<Integer> itr = li.iterator();
...
li.add("xxx");

改用

ListIterator<Integer> itr = li.listIterator();
...
itr.add("xxx");

添加时候完全交给迭代器进行完成

正确代码

LinkedList<Integer> li = new LinkedList<Integer>();
li.add(0);
for(int i = 1; i < 3; ++i){
    int size = li.size();
    ListIterator<Integer> itr = li.listIterator();
    for(int j = 0; j < size; ++j){
        itr.add(itr.next()+1);
    }
}
li.forEach(System.out::println);

---

问题分析

1、先看报错

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.117 sec <<< FAILURE!
test1(MainTest)  Time elapsed: 0.015 sec  <<< ERROR!
java.util.ConcurrentModificationException
	at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:966)
	at java.util.LinkedList$ListItr.next(LinkedList.java:888)
	at MainTest.test1(MainTest.java:17)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

2、找到对我们有用的信息

java.util.ConcurrentModificationException
	at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:966)
	at java.util.LinkedList$ListItr.next(LinkedList.java:888)
	at MainTest.test1(MainTest.java:17)

可以看到，报错因为我们执行到 li.add(itr.next()+1);时候报错

为什么报错是因为在LinkedList中的子类ListItr的next方法中888行，next方法又调用了checkForComodification方法报错，所以我们去看一下LinkedList的源码分别找到888和966行

分别如下

从图中可以看出来，结果了，因为modCount 与expectedModCount不相等，所以就抛出了异常。那为什么不相等呢？我们看看modCount 和expectedModCount究竟是啥。

modcount大概的作用呢就是用作统计被修改的次数，也就是当你的整体的结构发生修改，eg：add、remove的时候他就会++ 或者–，从而就会造成正在迭代的数据出现不正确的结果，如果该字段发生改变就会抛出ConcurrentModificationException异常

now，你maybe大概明白了，因为你在进行add的时候使得modCount发生了改变。

---

有意思的事

你或许会发现当你在执行第一次循环（i=1）的时候程序是正常执行的，但是当你执行第二次循环的时候报错了，为什么呢？

第一次循环（i=1）

第一次（i=1）的时候，li.size()的大小是1，里面只有一个值0，所以在进行循环

Iterator<Integer> itr = li.iterator();
for(int j = 0; j < size; ++j){
     li.add(itr.next()+1);
}

的时候，你只是执行了一次，也就是说：

你在li.add()这个方法执行了一次就退出了j循环，当你调用itr.next()+1的时候，他的modCount和expectedModCount的值是一样的,所以能够正常返回，当你执行结束li.add的时候modCount值发生了modCount++的操作，但是这个时候你已经退出循环了，无所谓。

第二次循环（i=2）

1)这个时候你需要仔细分析一下：

1：li 中的元素现在有0、1，

2：li.size()的值是2,也就是会进行2次 J循环

2)重头戏:

当j=0的时候进入了第一次循环这个时候执行li.add(itr.next()+1)的时候，你说有没有出现异常，答案是没有！

因为这个过程就行第一次循环的那一部分阐述一样，当他第一次执行itr.next()的时候modCount值是相等的，所以能够正常返回数值，而执行到li.add()的时候li发生了add操作导致modCount++，然后这个时候执行完这一行他就继续下一次循环。

当j = 1的时候，这个时候他要执行itr.next()获取值，就会去LinkedList中的next方法中去，在获取的时候会先执行checkForComodification这个方法去校验modCount和expectedModCount是否相等，如果不相等就说明发生了改变就会抛出ConcurrentModificationException异常。

也就是说当你j=1的时候执行itr.next发现了modCount值变化了，所以就抛出了异常。