fail-fast 快速失败 fail-safe 安全失败
说的是在Iterator遍历的过程中，是不能够修改集合数据的，否则就会抛出ConcurrentModificationException。
看个demo
执行结果
看一下我们第35行抛了异常 ConcurrentModificationException
追一下看看 ArrayList的第850行
这个方法是通过迭代器获取下一个元素
checkForComodification(); //问题就在这了，获取之前先进行一次判断
就是这了，如果判断成立直接抛得ConcurrentModificationException异常
我们看一下modCount和 expectedModCount分别是啥东西
modCount是AbstractList的一个属性，
大概意思就是 当集合的结构发生改变或者size发生变化时，modCount会发生变化
看一下ArrayList的几个会改变集合结构的方法 remove() add()
执行前都会有modCount++操作，也就是说只要集合的结构发生改变，这个modCount就会自增1
再看一下expectedModCount,
结了，也就是初始创建迭代器的时候就会expectedModCount = modCount
也就是说 迭代器在遍历的过程中，每次调用next()方法都会重新校验一下，看看这个modCount变没变，也就是有没有人修改了集合的结构，如果有直接抛异常ConcurrentModificationException
思考一下为什么不允许迭代器遍历的过程中修改集合结构？
大概是因为这边在这遍历查着，那边让人改了 会产生很奇怪的结果吧。
证明一下猜想。首先应从hasNext() next()这两个方法入手， 如何判断下一个元素存在的
这是ArrayList内部的迭代器实现，看出两个重要的属性，cursor size
看注释也看得出来，cursor就是游标 是迭代器内部的属性 从0开始遍历，
size是集合整体的大小 是ArrayList的属性，
hasNext()方法判断的就是当前游标和size
next()方法会使得游标+1 然后会记录一下最后一次取出元素的位置 lastRet(也就是刚才游标的位置)
那就证明了，如果我们从外部修改了集合的结构，集合的size会发生变化 但是游标cursor不会改，这不就会有问题了吗
最后看一下迭代器自带的remove()方法
先判断下modCount //确保没人傻了吧唧的从外部修改过集合结构
执行remove； //删的是lastRet位置(也就是迭代器最新一次取出来的元素)
cursor = lastRet; //游标并没有+1 保持不变
lastRet = -1; //最新一次取出来的元素已经被干掉了，给-1
expectedModCount = modCount; //重新对一下expectedModCount
好家伙，不知不觉把迭代器源码就瞅了一遍
fail-safe
一般的讲 Java.util包下的集合类都是fail-fast的，因为使用迭代器遍历的时候增删元素不安全
那么有不安全就有安全的， java.util.cuncurrent并发包下的集合就很安全
看个demo
一模一样的操作，换了copyOnWriteArrayList这个集合就可以了，这是为啥呢？ (程序员的病: 为啥不行呢？ 为啥又行呢？)
iterator() 传入 元素数组，0
看出来了 new 的时候保存了一份当前集合元素快照，
即使迭代器遍历的过程中集合发生改变也跟我没关系了，我遍历的始终是迭代器保存的快照 over