fail-fast究竟是个什么鬼

最新推荐文章于 2024-10-29 16:25:53 发布

转载最新推荐文章于 2024-10-29 16:25:53 发布 · 538 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://blog.youkuaiyun.com/yjn1995/article/details/99471191

易筋经——Java 专栏收录该内容

23 篇文章

订阅专栏

文章目录

概念引入
实例分析
集合类中的fail-fast
异常分析
异常原理
总结

概念引入

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

在系统设计中，快速失效系统一种可以立即报告任何可能表明故障的情况的系统。快速失效系统通常设计用于停止正常操作，而不是试图继续可能存在缺陷的过程。这种设计通常会在操作中的多个点检查系统的状态，因此可以及早检测到任何故障。快速失败模块的职责是检测错误，然后让系统的下一个最高级别处理错误。
其实，这是一种理念，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。
ConcurrentModificationException通常在方法检测到对象发生了并发修改，但程序不允许这种修改时被抛出。很多时候正是因为代码中抛出了ConcurrentModificationException，很多程序员就会很困惑，明明自己的代码并没有在多线程环境中执行，为什么会抛出这种并发有关的异常呢？这种情况在什么情况下才会抛出呢？我们就来深入分析一下。

异常分析

List<String> userNames = new ArrayList<String>() {{
    add("Jobs");
    add("jobs");
    add("JobsSteven");
    add("J");
}};
for (String userName : userNames) {
    if (userName.equals("Jobs")) {
        userNames.remove(userName);
    }
}
System.out.println(userNames);

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

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("Jobs");
		    add("jobs");
		    add("JobsSteven");
		    add("J");
    }};

    Iterator iterator = userNames.iterator();
    do
    {
        if(!iterator.hasNext())
            break;
        String userName = (String)iterator.next();
        if(userName.equals("Jobs"))
            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进行了比较，如果二者不想等，则抛出ConcurrentModificationException。那么，modCount和expectedModCount是什么？是什么原因导致他们的值不想等的呢？modCount是ArrayList中的一个成员变量。它表示该集合实际被修改的次数。

List<String> userNames = new ArrayList<String>() {{
    add("Jobs");
    add("jobs");
    add("JobsSteven");
    add("J");
}};

当使用以上代码初始化集合之后该变量就有了。初始值为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
}

可以看到，remove方法只修改了modCount，并没有对expectedModCount做任何操作。

再看一下内部类Itr的remove方法。

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

            try {
                ArrayList.this.remove(lastRet);
                cursor = lastRet;
                lastRet = -1;
                expectedModCount = modCount;
            } catch (IndexOutOfBoundsException ex) {
                throw new ConcurrentModificationException();
            }
        }

expectedModCount = modCount; 这行代码将modCount赋给了expectedModCount，所以在后面调用checkForComodification() 时不会报错。关于cursor，lastRet的变化，可以再看看源码的next()方法，将两个方法结合起来看。原理就是next方法调用时，索引+1，移除了一个元素后，索引-1。

总结

简单总结一下，之所以会抛出ConcurrentModificationException异常，是因为我们的代码中使用了增强for循环，而在增强for循环中，集合遍历是通过Iterator进行的，但是元素的add/remove却是直接使用的集合类自己的方法。这就导致iterator在遍历的时候，会发现有一个元素在iterator自己不知不觉的情况下就被删除/添加了，就会抛出一个异常，用来提示用户，可能发生了并发修改！
所以，在使用Java的集合类的时候，如果发生ConcurrentModificationException，优先考虑fail-fast有关的情况，实际上这里并没有真的发生并发，只是Iterator使用了fail-fast的保护机制，只要他发现有某一次修改是未经过iterator自己进行的，那么就会抛出异常。

这是一篇转载文章，笔者只是做了一点修改。原文地址：fail-fast究竟是个什么鬼？
吐槽一下优快云，没有转载功能，还要复制粘贴。。。