fail-fast和fail-safe - Alias的博客

fail-fast和fail-safe

java

发布于：2022年11月15日

fail-fast和fail-safe

什么是fail-fast

在维基百科中，关于fail-fast的解释翻译如下：

在系统设计中，快速失效系统一种可以立即报告任何可能表明故障的情况的系统。快速失效系统通常设计用于停止正常操作，而不是试图继续可能存在缺陷的过程。这种设计通常会在操作中的多个点检查系统的状态，因此可以及早检测到任何故障。快速失败模块的职责是检测错误，然后让系统的下一个最高级别处理错误。

其实说白了就是在做系统设计时优先考虑异常情况，一旦发现异常立刻上报

一个简单的例子：

1
2
3
4
5
6
public int divide(int divisor,int dividend){
    if(divisor == 0){
        throw new RuntimeException("divisor can't be null");
    }
    return dividend/divisor;
}

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。

示例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
List<String> userNames = new ArrayList<String>() {{
    add("Alias");
    add("alias");
    add("lsh");
    add("A");
}};

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

System.out.println(userNames);

以上代码，运行时会发生以下异常：

1
2
3
4
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其实是依赖了while循环和Iterator实现的。

异常原理

通过这行异常：

1
java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)

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

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

如上，在该方法中对modCount和expectedModCount进行了比较，如果二者不相等，则抛出CMException。

那么，modCount和expectedModCount是什么？是什么原因导致他们的值不相等的呢？

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

1
2
3
4
5
6
List<String> userNames = new ArrayList<String>() {{
    add("Alias");
    add("alias");
    add("lsh");
    add("A");
}};

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

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

1
Iterator iterator = userNames.iterator();

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

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

那么，接着我们看下userNames.remove(userName);方法里面做了什么事情，为什么会导致expectedModCount和modCount的值不一样。

通过翻阅代码，我们也可以发现，remove方法核心逻辑如下：

1
2
3
4
5
6
7
8
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的保护机制，只要他发现有某一次修改是未经过自己进行的，那么就会抛出异常。

fail-safe

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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public static void main(String[] args) {
    List<String> userNames = new CopyOnWriteArrayList<String>() {{
        add("Alias");
        add("alias");
        add("lsh");
        add("A");
    }};

    userNames.iterator();

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

    System.out.println(userNames);
}

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

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

所以，CopyOnWriteArrayList中的迭代器在迭代的过程中不需要做fail-fast的并发检测。（因为fail-fast的主要目的就是识别并发，然后通过异常的方式通知用户）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public static void main(String[] args) {
    List<String> userNames = new CopyOnWriteArrayList<String>() {{
        add("Alias");
        add("alias");
        add("lsh");
        add("A");
    }};

    Iterator it = userNames.iterator();

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

    System.out.println(userNames);

    while(it.hasNext()){
        System.out.println(it.next());
    }
}

输出结果为：

1
2
3
4
5
[alias, lsh, A]
Alias
alias
lsh
A

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

Copy-On-Write

在了解了CopyOnWriteArrayList之后，不知道大家会不会有这样的疑问：他的add/remove等方法都已经加锁了，还要copy一份再修改干嘛？多此一举？同样是线程安全的集合，这玩意和Vector有啥区别呢？

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

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

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

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

1
2
3
public E get(int index) {
    return get(getArray(), index);
}

这样做的好处是我们可以对CopyOnWrite容器进行并发的读，当然，这里读到的数据可能不是最新的。因为写时复制的思想是通过延时更新的策略来实现数据的最终一致性的，并非强一致性。

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

如何在遍历的同时删除ArrayList中的元素

普通for循环

1
2
3
4
5
6
7
8
9
10
11
12
13
List<String> userNames = new ArrayList<String>() {{
    add("Alias");
    add("alias");
    add("lsh");
    add("A");
}};

for (int i = 0; i < 1; i++) {
    if (userNames.get(i).equals("Alias")) {
        userNames.remove(i);
    }
}
System.out.println(userNames);

这种方案其实存在一个问题，那就是remove操作会改变List中元素的下标，可能存在漏删的情况

直接使用Iterator

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
List<String> userNames = new ArrayList<String>() {{
    add("Alias");
    add("alias");
    add("lsh");
    add("A");
}};

Iterator iterator = userNames.iterator();

while (iterator.hasNext()) {
    if (iterator.next().equals("Alias")) {
        iterator.remove();
    }
}
System.out.println(userNames);

如果直接使用Iterator提供的remove方法，那么就可以修改到expectedModCount的值。那么就不会再抛出异常了。

使用Java 8中提供的filter过滤

1
2
3
4
5
6
7
8
9
List<String> userNames = new ArrayList<String>() {{
    add("Alias");
    add("alias");
    add("lsh");
    add("A");
}};

userNames = userNames.stream().filter(userName -> !userName.equals("Alias")).collect(Collectors.toList());
System.out.println(userNames);

增强for

如果，我们非常确定在一个集合中，某个即将删除的元素只包含一个的话， 比如对Set进行操作，那么其实也是可以使用增强for循环的，只要在删除之后，立刻结束循环体，不要再继续进行遍历就可以了，也就是说不让代码执行到下一次的next方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
List<String> userNames = new ArrayList<String>() {{
        add("Alias");
        add("alias");
        add("lsh");
        add("A");
    }};

    for (String userName : userNames) {
        if (userName.equals("Alias")) {
            userNames.remove(userName);
            break;
        }
    }
    System.out.println(userNames);

直接使用fail-safe集合类

1
2
3
4
5
6
7
8
9
10
11
12
ConcurrentLinkedDeque<String> userNames = new ConcurrentLinkedDeque<String>() {{
    add("Alias");
    add("alias");
    add("lsh");
    add("A");
}};

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

博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议

本文永久链接是：http://levialias.top/2022/11/15/fail-fast%E5%92%8Cfail-safe/

更新于：2022年11月15日

java

评论