Java集合框架剖析（5）----fail-fast机制

叁歲伎倆 2022-05-28 07:39 84阅读 0赞

在JDK的Collection中我们时常会看到类似于这样的话：

例如，ArrayList:

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

注意，迭代器的快速失败行为不能得到保证，一般来说，存在非同步的并发修改时，不可能作出任何坚决的保证。快速失败迭代器尽最大努力抛出 ConcurrentModificationException。因此，编写依赖于此异常的程序的做法是错误的，正确做法是：迭代器的快速失败行为应该仅用于检测程序错误。

在这两段话中反复地提到”快速失败”。那么何为”快速失败”机制呢？

“快速失败”也就是fail-fast，它是Java集合的一种错误检测机制。当**多个线程**对集合进行结构上的改变的操作时，有可能会产生fail-fast机制。记住是有可能，而不是一定。例如：假设存在两个线程（线程1、线程2），线程1通过Iterator在遍历集合A中的元素，在某个时候线程2修改了集合A的结构（是结构上面的修改，而不是简单的修改集合元素的内容），那么这个时候程序就会抛出 ConcurrentModificationException 异常，从而产生fail-fast机制。

所以第一点在并发的情况下使用ArrayList,HashMap不是完全安全的。

## 示例代码 ##

![这里写图片描述][70 1]  
运行结果  
![这里写图片描述][70 2]

## 原因分析 ##

fail-fast产生的原因就在于程序在对 collection 进行迭代时，某个线程对该 collection 在结构上对其做了修改，这时迭代器就会抛出 ConcurrentModificationException 异常信息，从而产生 fail-fast。

要了解fail-fast机制，我们首先要对ConcurrentModificationException 异常有所了解。当方法检测到对象的并发修改，但不允许这种修改时就抛出该异常。同时需要注意的是，该异常不会始终指出对象已经由不同线程并发修改，如果单线程违反了规则，同样也有可能会抛出改异常。

诚然，迭代器的快速失败行为无法得到保证，它不能保证一定会出现该错误，但是快速失败操作会尽最大努力抛出ConcurrentModificationException异常，所以因此，为提高此类操作的正确性而编写一个依赖于此异常的程序是错误的做法，正确做法是：ConcurrentModificationException 应该仅用于检测 bug。下面我将以ArrayList为例进一步分析fail-fast产生的原因。

从前面我们知道fail-fast是在操作迭代器时产生的。现在我们来看看ArrayList中迭代器的源代码：  
![这里写图片描述][70 3]

从上面的源代码我们可以看出，迭代器在调用next()、remove()方法时都是调用checkForComodification()方法，该方法主要就是检测modCount == expectedModCount ? 若不等则抛出ConcurrentModificationException 异常，从而产生fail-fast机制。所以要弄清楚为什么会产生fail-fast机制我们就必须要用弄明白为什么modCount != expectedModCount ，他们的值在什么时候发生改变的。

expectedModCount 是在Itr中定义的：int expectedModCount = ArrayList.this.modCount;所以他的值是不可能会修改的，所以会变的就是modCount。modCount是在 AbstractList 中定义的，为全局变量：

![这里写图片描述][70 4]  
那么他什么时候因为什么原因而发生改变呢？请看ArrayList的源码：  
![这里写图片描述][70 5]  
从上面的源代码我们可以看出，ArrayList中无论add、remove、clear方法只要是涉及了改变ArrayList元素的个数的方法都会导致modCount的改变。所以我们这里可以初步判断由于**expectedModCount 得值与modCount**的改变不同步，导致两者之间不等从而产生fail-fast机制。  
其主要的逻辑还是防止在并发环境下所产生的错误。

## fail-fast解决办法 ##

方案一：在遍历过程中所有涉及到改变modCount值得地方全部加上synchronized或者直接使用Collections.synchronizedList，这样就可以解决。但是不推荐，因为增删造成的同步锁可能会阻塞遍历操作。

方案二：使用CopyOnWriteArrayList来替换ArrayList。推荐使用该方案。

CopyOnWriteArrayList为何物？ArrayList 的一个线程安全的变体，其中所有可变操作（add、set 等等）都是通过对底层数组进行一次新的复制来实现的。 该类产生的开销比较大，但是在两种情况下，它非常适合使用。

1：在不能或不想进行同步遍历，但又**需要从并发线程中排除冲突**时。  
2：当**遍历操作的数量大大超过可变操作的数量时**。

遇到这两种情况使用CopyOnWriteArrayList来替代ArrayList再适合不过了。

那么为什么CopyOnWriterArrayList可以替代ArrayList呢？

第一、CopyOnWriterArrayList的无论是从数据结构、定义都和ArrayList一样。它和ArrayList一样，同样是实现List接口，底层使用数组实现。在方法上也包含add、remove、clear、iterator等方法。

第二、CopyOnWriterArrayList根本就不会产生ConcurrentModificationException异常，也就是它使用迭代器完全不会产生fail-fast机制。请看：  
![这里写图片描述][70 6]  
CopyOnWriterArrayList的方法根本就没有像ArrayList中使用checkForComodification方法来判断expectedModCount 与 modCount 是否相等。它为什么会这么做，凭什么可以这么做呢？我们以add方法为例：  
![这里写图片描述][70 7]  
CopyOnWriterArrayList的add方法与ArrayList的add方法有一个最大的不同点就在于，下面三句代码：  
![这里写图片描述][70 8]

就是这三句代码使得CopyOnWriterArrayList不会抛ConcurrentModificationException异常。他们所展现的魅力就在于copy原来的array，再在copy数组上进行add操作，这样做就完全不会影响COWIterator中的array了。

所以CopyOnWriterArrayList所代表的核心概念就是：任何对array在结构上有所改变的操作（add、remove、clear等），CopyOnWriterArrayList都会copy现有的数据，再在copy的数据上修改，这样就不会影响COWIterator中的数据了，修改完成之后改变原有数据的引用即可。同时这样造成的代价就是产生大量的对象，同时数组的copy也是相当有损耗的。

[70]: /images/20220528/9f8c747d6dc047ab95a0252faa0a55b4.png
[70 1]: /images/20220528/70effcbabc184767ba64691ca71c581e.png
[70 2]: /images/20220528/07937ef918d349dfb5120d4da1ba4da7.png
[70 3]: /images/20220528/8aeaccc482ab4beaad05aa4d06372734.png
[70 4]: /images/20220528/bbaab6066e834fbaba9407cf2e847800.png
[70 5]: /images/20220528/2aa269493bc842d6b319286d1d97768a.png
[70 6]: /images/20220528/63717a4a57114d64a8d38d208e63e5cf.png
[70 7]: /images/20220528/68f36baf529f45a790d713438ff5ffa7.png
[70 8]: /images/20220528/be86168ba388445ea073d3a5a9c65a5f.png