对map,list等进行遍历的时候，不做增加，删除的时候，fori,fore,iterator等方式都没太大区别，当需要在遍历的过程中，增加或删除元素的时候，就会遇到异常了。
具体参考这篇文章:
在foreach循环里进行remove/add操作
具体的remove/add参考上面的文章就好，接下来说一下我最近做的蠢事。
首先说一下错误的做法，在增强for循环里，进行add，和remove操作，会导致modCount和expectCount这2个值不一致。
我在用迭代器遍历Map的时候，先iterator.remove,然后map.put最后抛了异常，一开始心想，用了迭代器进行remove操作了，为什么还会抛这个异常呢，后来拍了拍脑袋，先remove,再add，也破坏了modCount和expectCount这2个值。
最后我用了2个数组，保存了迭代过程中产生的局部遍量，在退出循环之后，从2个数组取值，然后map.put，当然，最后数组取值的 时候又做了点蠢事，数组下标越界了。
+++++++++++++++++++++++我是分界线+++++++++++++++++++++++++
评论区有疑问，那就再补充一下细节。
贴代码
测试代码
先使用HashMap进行测试
public static void main(String[] args) {
Map<String, Object> map = new HashMap<>();
map.put("x",new Date());
map.put("y",new Date());
Iterator<Map.Entry<String, Object>> iterator = map.entrySet().iterator();
while (iterator.hasNext()) {
Map.Entry<String, Object> next = iterator.next();
System.out.println(next.getKey());
map.put("z",new Date());
}
}
根据控制台测试结果，在输出了第一个key
x之后，继续执行的时候抛出了java.util.ConcurrentModificationException异常。
我们查看异常堆栈，抛出异常的地方是java.util.HashMap.HashIterator#nextNode,1445行
根据代码，抛出异常的原因是modCount != expectedModCount。
这一行代码说明抛异常的原因就是2个count不相等造成的。
变量解释
来看一下modCount和expectedModCount具体代表什么意思。
modCount是HashMap的一个成员变量，用来表示HashMap被修改的次数
modCount值修改的时候，是在做put/remove等操作的时候
expectedModCount是HashMap的内部类java.util.HashMap.HashIterator的一个成员变量，初始化值为modCount
expectedModCount值修改的时候，除了初始化，只有一处调用：java.util.HashMap.HashIterator#remove
原因分析
前面看了代码了，知道异常抛出的原因是modCount != expectedModCount。
看代码，是使用迭代器遍历map，在迭代的过程中执行了put操作，根据代码可知，put操作是会改变modCount的值的，但put操作不会修改expectedModCount，expectedModCount的值只有在调用HashIterator#remove方法的时候才会被修改。
所以只修改了一个值，在执行完一次put操作，进入下一个循环的时候就会抛出异常。
安全容器
评论区也提出了使用安全的容器不会有这个异常。确实是这样，将HashMap换成ConcurrentHashMap，不会抛出这个异常。
可以看到代码完整的执行完了，并没有抛出异常。
关于安全容器，这里解释2个概念
fail-fast
fail-fast，即快速失败，它是Java集合的一种错误检测机制。当多个线程对集合（非fail-safe的集合类）进行结构上的改变的操作时，有可能会产生fail-fast机制，这个时候就会抛出ConcurrentModificationException（当方法检测到对象的并发修改，但不允许这种修改时就抛出该异常）。
同时需要注意的是，即使不是多线程环境，如果单线程违反了规则，同样也有可能会抛出改异常。
HashMap不是并发安全的容器，所以采用的是fail-fast机制。
刚才在看迭代器的源码的时候，expectedModCount的注释就写了这个变量是为了fast-fail准备的。
fail-safe
在Java中，除了一些普通的集合类以外，还有一些采用了fail-safe机制的集合类。这样的集合容器在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。
由于迭代时是对原集合的拷贝进行遍历，所以在遍历过程中对原集合所作的修改并不能被迭代器检测到，所以不会触发ConcurrentModificationException。
基于拷贝内容的优点是避免了ConcurrentModificationException，但同样地，迭代器并不能访问到修改后的内容，即：迭代器遍历的是开始遍历那一刻拿到的集合拷贝，在遍历期间原集合发生的修改迭代器是不知道的。
java.util.concurrent包下的容器都是安全失败，可以在多线程下并发使用，并发修改。
java.util.concurrent.ConcurrentHashMap是符合fail-safe语意的，但是并不是迭代是拷贝副本，创建EntrySet的时候，传入的是this,即修改的是自身集合
注释也作了说明，map的修改会反映到Set上
The set is backed by the map, so changes to the map are *reflected in the set, and vice-versa
关于ConcurrentHashMap是否存在拷贝，stackoverflow上有一些问答，供参考
总结
Java集合类设计时有2种保障机制，为不同场景下安全的使用集合提供了充分的保障。
我们开发时一般使用HashMap会更多，需要并发集合的时候才会考虑使用ConcurrentHashMap。
了解2种机制，可以更好的在实际开发过程中进行应用。
