一不当心就让Java开发踩坑的fail-fast是个什么鬼？

GitHub 2.1k Star 的Java工程师成神之路 ，不来了解一下吗?

GitHub 2.1k Star 的Java工程师成神之路 ，真的不来了解一下吗?

GitHub 2.1k Star 的Java工程师成神之路 ，真的肯定不来了解一下吗?

我在《为何阿里巴巴禁止在 foreach 循环里进行元素的 remove/add 操做》一文中曾经介绍过Java中的fail-fast机制，可是并无深刻介绍，本文，就来深刻介绍一下fail-fast。

什么是fail-fast

首先咱们看下维基百科中关于fail-fast的解释：

In systems design, a fail-fast system is one which immediately reports at its interface any condition that is likely to indicate a failure. Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process. Such designs often check the system's state at several points in an operation, so any failures can be detected early. The responsibility of a fail-fast module is detecting errors, then letting the next-highest level of the system handle them.

大概意思是：在系统设计中，快速失效系统一种能够当即报告任何可能代表故障的状况的系统。快速失效系统一般设计用于中止正常操做，而不是试图继续可能存在缺陷的过程。这种设计一般会在操做中的多个点检查系统的状态，所以能够及早检测到任何故障。快速失败模块的职责是检测错误，而后让系统的下一个最高级别处理错误。

其实，这是一种理念，说白了就是在作系统设计的时候先考虑异常状况，一旦发生异常，直接中止并上报。

举一个最简单的fail-fast的例子：

public int divide(int divisor,int dividend){
    if(dividend == 0){
        throw new RuntimeException("dividend can't be null");
    }
    return divisor/dividend;
}
复制代码

上面的代码是一个对两个整数作除法的方法，在divide方法中，咱们对被除数作了个简单的检查，若是其值为0，那么就直接抛出一个异常，并明确提示异常缘由。这其实就是fail-fast理念的实际应用。

这样作的好处就是能够预先识别出一些错误状况，一方面能够避免执行复杂的其余代码，另一方面，这种异常状况被识别以后也能够针对性的作一些单独处理。

怎么样，如今你知道fail-fast了吧，其实他并不神秘，你平常的代码中可能常常会在使用的。

既然，fail-fast是一种比较好的机制，为何文章标题说fail-fast会有坑呢？

缘由是Java的集合类中运用了fail-fast机制进行设计，一旦使用不当，触发fail-fast机制设计的代码，就会发生非预期状况。

集合类中的fail-fast

咱们一般说的Java中的fail-fast机制，默认指的是Java集合的一种错误检测机制。当多个线程对部分集合进行结构上的改变的操做时，有可能会产生fail-fast机制，这个时候就会抛出ConcurrentModificationException（后文用CME代替）。

CMException，当方法检测到对象的并发修改，但不容许这种修改时就抛出该异常。

不少时候正是由于代码中抛出了CMException，不少程序员就会很困惑，明明本身的代码并无在多线程环境中执行，为何会抛出这种并发有关的异常呢？这种状况在什么状况下才会抛出呢？咱们就来深刻分析一下。

异常复现

在Java中， 若是在foreach 循环里对某些集合元素进行元素的 remove/add 操做的时候，就会触发fail-fast机制，进而抛出CMException。

如如下代码：

List<String> userNames = new ArrayList<String>() {{
    add("Hollis");
    add("hollis");
    add("HollisChuang");
    add("H");
}};

for (String userName : userNames) {
    if (userName.equals("Hollis")) {
        userNames.remove(userName);
    }
}

System.out.println(userNames);
复制代码

以上代码，使用加强for循环遍历元素，并尝试删除其中的Hollis字符串元素。运行以上代码，会抛出如下异常：

Exception in thread "main" java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
at java.util.ArrayList$Itr.next(ArrayList.java:859)
at com.hollis.ForEach.main(ForEach.java:22)
复制代码

一样的，读者能够尝试下在加强for循环中使用add方法添加元素，结果也会一样抛出该异常。

在深刻原理以前，咱们先尝试把foreach进行解语法糖，看一下foreach具体如何实现的。

咱们使用jad工具，对编译后的class进行反编译，获得如下代码：

public static void main(String[] args) {
    // 使用ImmutableList初始化一个List
    List<String> userNames = new ArrayList<String>() {{
        add("Hollis");
        add("hollis");
        add("HollisChuang");
        add("H");
    }};

    Iterator iterator = userNames.iterator();
    do
    {
        if(!iterator.hasNext())
            break;
        String userName = (String)iterator.next();
        if(userName.equals("Hollis"))
            userNames.remove(userName);
    } while(true);
    System.out.println(userNames);
}
复制代码

能够发现，foreach实际上是依赖了while循环和Iterator实现的。

异常原理

经过以上代码的异常堆栈，咱们能够跟踪到真正抛出异常的代码是：

java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
复制代码

该方法是在iterator.next()方法中调用的。咱们看下该方法的实现：

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

如上，在该方法中对modCount和expectedModCount进行了比较，若是两者不想等，则抛出CMException。

那么，modCount和expectedModCount是什么？是什么缘由致使他们的值不想等的呢？

modCount是ArrayList中的一个成员变量。它表示该集合实际被修改的次数。

List<String> userNames = new ArrayList<String>() {{
    add("Hollis");
    add("hollis");
    add("HollisChuang");
    add("H");
}};
复制代码

当使用以上代码初始化集合以后该变量就有了。初始值为0。

expectedModCount 是 ArrayList中的一个内部类——Itr中的成员变量。

Iterator iterator = userNames.iterator();
复制代码

以上代码，便可获得一个 Itr类，该类实现了Iterator接口。

expectedModCount表示这个迭代器预期该集合被修改的次数。其值随着Itr被建立而初始化。只有经过迭代器对集合进行操做，该值才会改变。

那么，接着咱们看下userNames.remove(userName);方法里面作了什么事情，为何会致使expectedModCount和modCount的值不同。

经过翻阅代码，咱们也能够发现，remove方法核心逻辑以下：

private void fastRemove(int index) {
    modCount++;
    int numMoved = size - index - 1;
    if (numMoved > 0)
        System.arraycopy(elementData, index+1, elementData, index,
                         numMoved);
    elementData[--size] = null; // clear to let GC do its work
}
复制代码

能够看到，它只修改了modCount，并无对expectedModCount作任何操做。

简单画一张图描述下以上场景：



简单总结一下，之因此会抛出CMException异常，是由于咱们的代码中使用了加强for循环，而在加强for循环中，集合遍历是经过iterator进行的，可是元素的add/remove倒是直接使用的集合类本身的方法。这就致使iterator在遍历的时候，会发现有一个元素在本身不知不觉的状况下就被删除/添加了，就会抛出一个异常，用来提示用户，可能发生了并发修改！

因此，在使用Java的集合类的时候，若是发生CMException，优先考虑fail-fast有关的状况，实际上这里并无真的发生并发，只是Iterator使用了fail-fast的保护机制，只要他发现有某一次修改是未通过本身进行的，那么就会抛出异常。

关于如何解决这种问题，咱们在《为何阿里巴巴禁止在 foreach 循环里进行元素的 remove/add 操做》中介绍过，这里再也不赘述了。

fail-safe

为了不触发fail-fast机制，致使异常，咱们可使用Java中提供的一些采用了fail-safe机制的集合类。

这样的集合容器在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。

java.util.concurrent包下的容器都是fail-safe的，能够在多线程下并发使用，并发修改。同时也能够在foreach中进行add/remove 。

咱们拿CopyOnWriteArrayList这个fail-safe的集合类来简单分析一下。

public static void main(String[] args) {
    List<String> userNames = new CopyOnWriteArrayList<String>() {{
        add("Hollis");
        add("hollis");
        add("HollisChuang");
        add("H");
    }};

    userNames.iterator();

    for (String userName : userNames) {
        if (userName.equals("Hollis")) {
            userNames.remove(userName);
        }
    }

    System.out.println(userNames);
}
复制代码

以上代码，使用CopyOnWriteArrayList代替了ArrayList，就不会发生异常。

fail-safe集合的全部对集合的修改都是先拷贝一份副本，而后在副本集合上进行的，并非直接对原集合进行修改。而且这些修改方法，如add/remove都是经过加锁来控制并发的。

因此，CopyOnWriteArrayList中的迭代器在迭代的过程当中不须要作fail-fast的并发检测。（由于fail-fast的主要目的就是识别并发，而后经过异常的方式通知用户）

可是，虽然基于拷贝内容的优势是避免了ConcurrentModificationException，但一样地，迭代器并不能访问到修改后的内容。如如下代码：

public static void main(String[] args) {
    List<String> userNames = new CopyOnWriteArrayList<String>() {{
        add("Hollis");
        add("hollis");
        add("HollisChuang");
        add("H");
    }};

    Iterator it = userNames.iterator();

    for (String userName : userNames) {
        if (userName.equals("Hollis")) {
            userNames.remove(userName);
        }
    }

    System.out.println(userNames);

    while(it.hasNext()){
        System.out.println(it.next());
    }
}
复制代码

咱们获得CopyOnWriteArrayList的Iterator以后，经过for循环直接删除原数组中的值，最后在结尾处输出Iterator，结果发现内容以下：

[hollis, HollisChuang, H]
Hollis
hollis
HollisChuang
H
复制代码

迭代器遍历的是开始遍历那一刻拿到的集合拷贝，在遍历期间原集合发生的修改迭代器是不知道的。

Copy-On-Write

在了解了CopyOnWriteArrayList以后，不知道你们会不会有这样的疑问：他的add/remove等方法都已经加锁了，还要copy一份再修改干吗？画蛇添足？一样是线程安全的集合，这玩意和Vector有啥区别呢？

Copy-On-Write简称COW，是一种用于程序设计中的优化策略。其基本思路是，从一开始你们都在共享同一个内容，当某我的想要修改这个内容的时候，才会真正把内容Copy出去造成一个新的内容而后再改，这是一种延时懒惰策略。

CopyOnWrite容器即写时复制的容器。通俗的理解是当咱们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，而后新的容器里添加元素，添加完元素以后，再将原容器的引用指向新的容器。

CopyOnWriteArrayList中add/remove等写方法是须要加锁的，目的是为了不Copy出N个副本出来，致使并发写。

可是，CopyOnWriteArrayList中的读方法是没有加锁的。

public E get(int index) {
    return get(getArray(), index);
}
复制代码

这样作的好处是咱们能够对CopyOnWrite容器进行并发的读，固然，这里读到的数据可能不是最新的。由于写时复制的思想是经过延时更新的策略来实现数据的最终一致性的，并不是强一致性。

**因此CopyOnWrite容器是一种读写分离的思想，读和写不一样的容器。**而Vector在读写的时候使用同一个容器，读写互斥，同时只能作一件事儿。