fail-fast与fail-safe工作机制

前言

在Collection集合的各个类中，有线程安全和线程不安全的两大类版本。
对于线程不安全的类，并发情况下可能会出现fail-fast(快速失败)，而线程安全的类，可能会出现fail-safe(安全失败)

并发修改

当一个或多个线程正在遍历一个集合Collection的时候(Iterator遍历，增强for循环也属于迭代器遍历，使用普通索引进行遍历不会抛出异常)，而此时另一个线程修改了这个集合的内容(如添加，删除或者修改)这就是并发修改的情况。

fail-fast快速失败

fail-fast机制：当遍历一个集合对象时，如果集合对象的结构被修改了，就会抛出ConcurrentModficationExcetion异常，防止在对集合进行遍历过程中，出现了意料之外的修改，会通过异常暴露反应过来。

实现方式：

• 当前迭代器会维护一个计数器，即expectedModCount，记录已经修改的次数，在进入遍历时候，会把实时修改次数modCount赋值给expectedModCount，之后再迭代过程中两个数据不相等就会抛出异常。

注：即使不是多线程环境，如果单线程违反了规则，同样也有可能抛出异常

迭代器的快速失败行为无法得到保证，因为一般来说，不可能对是否出现不同步并发修改做出任何硬性保证。快速失败迭代器会尽最大努力抛出ConcurrentModificationException，因此为提高这类迭代器的正确性，而编写一个依赖于这个异常的程序是错误做法，迭代器的快速失败行为应该仅用于检测BUG。

只有在迭代过程中修改了元素的结构，在调用next()方法时才会抛出该异常，也就是说，如果迭代过程发生了修改，但之后没有调用next()迭代，该异常就不会抛出(该异常的机制是告诉你，当前迭代器进行操作是有问题的，因为集合对象现在状态发生了变化)

下面是抛出异常的情况：

单线程抛出fail-fast情况

在单线程下，如果使用迭代器对象遍历集合过程中，修改集合对象结构，如下：

// 1.iterator迭代，抛出ConcurrentModificationException异常
Iterator<String> iterator = list.iterator();
while (iterator.hasNext()) {
  String s = iterator.next();
  System.out.println(s);
  // 修改集合结构
  if ("s2".equals(s)) {
    //使用了list中的remove方法
    list.remove(s);
  }
}

// 2.foreach迭代，抛出ConcurrentModificationException异常
for (String s : list) {
  System.out.println(s);
  // 修改集合结构
  if ("s2".equals(s)) {
  //使用了list中的remove方法
    list.remove(s);
  }
}

想要避免上面情况就需要使用呢Iterator中对象中remobe方法，而不是list中的remove方法，代码如下：

// 3.iterator迭代，使用iterator.remove()移除元素不会抛出异常
Iterator<String> iterator2 = list.iterator();
while (iterator2.hasNext()) {
  String s = iterator2.next();
  System.out.println(s);
  // 修改集合结构
  if ("s2".equals(s)) {
  iterator2.remove();
  }
}

这样就不会抛出异常。原因在于如果直接调用list.remove那会影响计数器(增加、删除都会影响计数器，但是修改不会)，就会导致modCount != expectedModCount从而抛出异常。源码如下：

final void checkForComodification() {
            if (modCount != expectedModCount)
                throw new ConcurrentModificationException();
        }

但是调用迭代器的remove，就会重新更新expectedModCount的值，让他与modCount相等，代码如下：

public void remove() {
            if (lastRet < 0)
                throw new IllegalStateException();
            checkForComodification();

            try {
                //调用这个方法会更新modCount
                ArrayList.this.remove(lastRet);
                cursor = lastRet;
                lastRet = -1;
                //重新赋值了expectedModCount
                expectedModCount = modCount;
            } catch (IndexOutOfBoundsException ex) {
                throw new ConcurrentModificationException();
            }
        }

多线程抛出fail-fast

在多线程下，如果对集合对象进行并发修改，那么就会可能抛出ConcurrentModificationException异常，但是不能保证一定会抛出，因为必须迭代过程修改了元素，并且调用了next方法才会抛出异常，如果修改了但没有调用next迭代就不会抛出异常。

fail-safe安全失败

与fail-fast相对应的，就是fail-safe机制，在JUC包集合都是有这种机制实现的。

fail-safe指的是：在安全的副本(或者没有提供修改一操作的正本)上进行遍历，集合修改和副本的遍历时没有任何关系的，但是缺点很明显，就是读取不到最新数据，这就是CAP理论中C(Consistency)和A(Availability)的矛盾，即一致性和可用性的矛盾。

上面的fail-fast发生时，程序会抛出异常，而fail-safe是一个概念，并发容器并发修改不会抛出异常，并发容器都是围绕着快照版本就行的操作，并没有modCount等数值检查，你可以并发读取，不会抛出异常，但是不保证你的遍历读取的值和当前集合对象状态是一致的。

所以fail-safe迭代缺点是：首先不能保证返回集合更新后的数据，因为其工作在集合的科荣上，而非集合本身，其次创建集合拷贝需要相应的开销，包括时间和内存。

JUC包中集合的迭代，如ConcurrentHashMap、CopyOnWriteArrayList等默认的都是faile-safe

总结

当我们对象集合结构上做出改变(add/remove等，不包括set)时候，fail-fast就会抛出异常，但是对于采用了fail-safe机制来说，就不会抛出异常。

这是因为fail-safe机制会复制原集合的一份数据出来，然后在复制的那份数据遍历。
fail-safe虽然不抛出异常，但是存在的问题：

• 复制时需要额外空间和时间的开销
• 不能保证遍历的是最新内容(不能保证实时的一致性)