在JDK的Collection中我們時常會看到類似于這樣的話：

例如，ArrayList:

注意，迭代器的快速失敗行為無法得到保證，因為一般來說，不可能對是否出現(xiàn)不同步并發(fā)修改做出任何硬性保證。快速失敗迭代器會盡最大努力拋出 ConcurrentModificationException。因此，為提高這類迭代器的正確性而編寫一個依賴于此異常的程序是錯誤的做法：迭代器的快速失敗行為應(yīng)該僅用于檢測 bug。

???HashMap中：

注意，迭代器的快速失敗行為不能得到保證，一般來說，存在非同步的并發(fā)修改時，不可能作出任何堅決的保證。快速失敗迭代器盡最大努力拋出 ConcurrentModificationException。因此，編寫依賴于此異常的程序的做法是錯誤的，正確做法是：迭代器的快速失敗行為應(yīng)該僅用于檢測程序錯誤。

??在這兩段話中反復(fù)地提到”快速失敗”。那么何為”快速失敗”機制呢？

“快速失敗”也就是 fail-fast，它是Java集合的一種錯誤檢查機制。當多個線程對集合進行結(jié)構(gòu)上的改變的操作時，有可能會產(chǎn)生 fail-fast 機制。記住是有可能，而不是一定，例如，假設(shè)存在線程（線程1、線程2），線程1通過Iterator在遍歷集合A中的元素，在某個時候線程2修改了集合A的結(jié)構(gòu)（是結(jié)構(gòu)上面的修改，而不是簡單的修改集合元素的內(nèi)容），那么這個時候程序就會拋出 ConcurrentModificationException 異常，從而產(chǎn)生fail-fast機制。

?

一、fail-fast 示例：

public class FailFastTest {private static List<Integer> list = new ArrayList<>();/*** @desc:線程one迭代list*/private static class threadOne extends Thread{public void run() {Iterator<Integer> iterator = list.iterator();while(iterator.hasNext()){int i = iterator.next();System.out.println("ThreadOne 遍歷:" + i);try {Thread.sleep(10);} catch (InterruptedException e) {e.printStackTrace();}}}}/*** @desc:當i == 3時，修改list*/private static class threadTwo extends Thread{public void run(){int i = 0 ; while(i < 6){System.out.println("ThreadTwo run：" + i);if(i == 3){list.remove(i);}i++;}}}public static void main(String[] args) {for(int i = 0 ; i < 10;i++){list.add(i);}new threadOne().start();new threadTwo().start();} }

運行結(jié)構(gòu)：

ThreadOne 遍歷:0 ThreadTwo run：0 ThreadTwo run：1 ThreadTwo run：2 ThreadTwo run：3 ThreadTwo run：4 ThreadTwo run：5 Exception in thread "Thread-0" java.util.ConcurrentModificationExceptionat java.util.ArrayList$Itr.checkForComodification(Unknown Source)at java.util.ArrayList$Itr.next(Unknown Source)at test.ArrayListTest$threadOne.run(ArrayListTest.java:23)

?

二、fail-fast 產(chǎn)生的原因：

通過上面的示例和講解，我初步知道fail-fast產(chǎn)生的原因就在于程序在對 collection 進行迭代時，某個線程對該 collection 在結(jié)構(gòu)上對其做了修改，這時迭代器就會拋出 ConcurrentModificationException 異常信息，從而產(chǎn)生 fail-fast。

要了解fail-fast機制，我們首先要對ConcurrentModificationException 異常有所了解。當方法檢測到對象的并發(fā)修改，但不允許這種修改時就拋出該異常。同時需要注意的是，該異常不會始終指出對象已經(jīng)由不同線程并發(fā)修改，如果單線程違反了規(guī)則，同樣也有可能會拋出改異常。

誠然，迭代器的快速失敗行為無法得到保證，它不能保證一定會出現(xiàn)該錯誤，但是快速失敗操作會盡最大努力拋出ConcurrentModificationException異常，所以因此，為提高此類操作的正確性而編寫一個依賴于此異常的程序是錯誤的做法，正確做法是：ConcurrentModificationException 應(yīng)該僅用于檢測 bug。下面我將以ArrayList為例進一步分析fail-fast產(chǎn)生的原因。

從前面我們知道fail-fast是在操作迭代器時產(chǎn)生的。現(xiàn)在我們來看看ArrayList中迭代器的源代碼：

private class Itr implements Iterator<E> {int cursor;int lastRet = -1;int expectedModCount = ArrayList.this.modCount;public boolean hasNext() {return (this.cursor != ArrayList.this.size);}public E next() {checkForComodification();/** 省略此處代碼 */}public void remove() {if (this.lastRet < 0)throw new IllegalStateException();checkForComodification();/** 省略此處代碼 */}final void checkForComodification() {if (ArrayList.this.modCount == this.expectedModCount)return;throw new ConcurrentModificationException();}}

?從上面的源代碼我們可以看出，迭代器在調(diào)用next()、remove()方法時都是調(diào)用checkForComodification()方法，該方法主要就是檢測modCount == expectedModCount ? 若不等則拋出ConcurrentModificationException 異常，從而產(chǎn)生fail-fast機制。所以要弄清楚為什么會產(chǎn)生fail-fast機制我們就必須要用弄明白為什么modCount != expectedModCount ，他們的值在什么時候發(fā)生改變的。

expectedModCount 是在Itr中定義的：int expectedModCount = ArrayList.this.modCount;所以他的值是不可能會修改的，所以會變的就是modCount。modCount是在 AbstractList 中定義的，為全局變量：

protected transient int modCount = 0;

那么他什么時候因為什么原因而發(fā)生改變呢？請看ArrayList的源碼：

public boolean add(E paramE) {ensureCapacityInternal(this.size + 1);/** 省略此處代碼 */}private void ensureCapacityInternal(int paramInt) {if (this.elementData == EMPTY_ELEMENTDATA)paramInt = Math.max(10, paramInt);ensureExplicitCapacity(paramInt);}private void ensureExplicitCapacity(int paramInt) {this.modCount += 1; //修改modCount/** 省略此處代碼 */}public boolean remove(Object paramObject) {int i;if (paramObject == null)for (i = 0; i < this.size; ++i) {if (this.elementData[i] != null)continue;fastRemove(i);return true;}elsefor (i = 0; i < this.size; ++i) {if (!(paramObject.equals(this.elementData[i])))continue;fastRemove(i);return true;}return false;}private void fastRemove(int paramInt) {this.modCount += 1; //修改modCount/** 省略此處代碼 */}public void clear() {this.modCount += 1; //修改modCount/** 省略此處代碼 */}

從上面的源代碼我們可以看出，ArrayList中無論add、remove、clear方法只要是涉及了改變ArrayList元素的個數(shù)的方法都會導(dǎo)致modCount的改變。所以我們這里可以初步判斷由于expectedModCount 得值與modCount的改變不同步，導(dǎo)致兩者之間不等從而產(chǎn)生fail-fast機制。知道產(chǎn)生fail-fast產(chǎn)生的根本原因了，我們可以有如下場景：

有兩個線程（線程A，線程B），其中線程A負責(zé)遍歷list、線程B修改list。線程A在遍歷list過程的某個時候（此時expectedModCount = modCount=N），線程B啟動，同時線程B增加一個元素，這是modCount的值發(fā)生改變（modCount + 1 = N + 1）。線程A繼續(xù)遍歷執(zhí)行next方法時，通告checkForComodification方法發(fā)現(xiàn)expectedModCount??= N??，而modCount = N + 1，兩者不等，這時就拋出ConcurrentModificationException 異常，從而產(chǎn)生fail-fast機制。

????????所以，直到這里我們已經(jīng)完全了解了fail-fast產(chǎn)生的根本原因了。知道了原因就好找解決辦法了。
?

三、fail-fast 解決方法：

通過前面的實例、源碼分析，我想各位已經(jīng)基本了解了fail-fast的機制，下面我就產(chǎn)生的原因提出解決方案。這里有兩種解決方案：

方案一：在遍歷過程中所有涉及到改變modCount 值的地方全部加上synchronized 或者直接使用 Collection synchronizedList，這樣就可以解決問題，但是不推薦，因為增刪造成的同步鎖可能會阻塞遍歷操作。

方案二：使用CopyOnWriteArrayList 替換 ArrayLIst，推薦使用該方案（即fail-safe）。

CopyOnWriteArrayList為何物？ArrayList 的一個線程安全的變體，其中所有可變操作（add、set 等等）都是通過對底層數(shù)組進行一次新的復(fù)制來實現(xiàn)的。 該類產(chǎn)生的開銷比較大，但是在兩種情況下，它非常適合使用。1：在不能或不想進行同步遍歷，但又需要從并發(fā)線程中排除沖突時。2：當遍歷操作的數(shù)量大大超過可變操作的數(shù)量時。遇到這兩種情況使用CopyOnWriteArrayList來替代ArrayList再適合不過了。那么為什么CopyOnWriterArrayList可以替代ArrayList呢？

第一、CopyOnWriterArrayList的無論是從數(shù)據(jù)結(jié)構(gòu)、定義都和ArrayList一樣。它和ArrayList一樣，同樣是實現(xiàn)List接口，底層使用數(shù)組實現(xiàn)。在方法上也包含add、remove、clear、iterator等方法。

第二、CopyOnWriterArrayList根本就不會產(chǎn)生ConcurrentModificationException異常，也就是它使用迭代器完全不會產(chǎn)生fail-fast機制。請看：

private static class COWIterator<E> implements ListIterator<E> {/** 省略此處代碼 */public E next() {if (!(hasNext()))throw new NoSuchElementException();return this.snapshot[(this.cursor++)];}/** 省略此處代碼 */}

??CopyOnWriterArrayList的方法根本就沒有像ArrayList中使用checkForComodification方法來判斷expectedModCount 與 modCount 是否相等。它為什么會這么做，憑什么可以這么做呢？我們以add方法為例：

public boolean add(E paramE) {ReentrantLock localReentrantLock = this.lock;localReentrantLock.lock();try {Object[] arrayOfObject1 = getArray();int i = arrayOfObject1.length;Object[] arrayOfObject2 = Arrays.copyOf(arrayOfObject1, i + 1);arrayOfObject2[i] = paramE;setArray(arrayOfObject2);int j = 1;return j;} finally {localReentrantLock.unlock();}}final void setArray(Object[] paramArrayOfObject) {this.array = paramArrayOfObject;}

CopyOnWriterArrayList的add方法與ArrayList的add方法有一個最大的不同點就在于，下面三句代碼：

Object[] arrayOfObject2 = Arrays.copyOf(arrayOfObject1, i + 1); arrayOfObject2[i] = paramE; setArray(arrayOfObject2);

就是這三句代碼使得CopyOnWriterArrayList不會拋ConcurrentModificationException異常。他們所展現(xiàn)的魅力就在于copy原來的array，再在copy數(shù)組上進行add操作，這樣做就完全不會影響COWIterator中的array了。

所以，CopyOnWriterArrayList所代表的核心概念就是：任何對array在結(jié)構(gòu)上有所改變的操作（add、remove、clear等），CopyOnWriterArrayList都會copy現(xiàn)有的數(shù)據(jù)，再在copy的數(shù)據(jù)上修改，這樣就不會影響COWIterator中的數(shù)據(jù)了，修改完成之后改變原有數(shù)據(jù)的引用即可。同時這樣造成的代價就是產(chǎn)生大量的對象，同時數(shù)組的copy也是相當有損耗的。
?

四、fail-safe 機制：

1、fail-safe 任何對集合結(jié)構(gòu)的修改都會在一個復(fù)制的集合上進行，因此不會拋出ConcurrentModificationException。

2、fail-safe 機制有兩個問題：

（1）需要復(fù)制集合，產(chǎn)生大量的無效對象，開銷大。

（2）無法保證讀取到的數(shù)據(jù)是目前原始結(jié)構(gòu)中的數(shù)據(jù)。

3、fail-safe例子：

import java.util.concurrent.ConcurrentHashMap; import java.util.Iterator;public class FailSafeExample {public static void main(String[] args){ConcurrentHashMap<String,String> premiumPhone = new ConcurrentHashMap<String,String>();premiumPhone.put("Apple", "iPhone");premiumPhone.put("HTC", "HTC one");premiumPhone.put("Samsung","S5");Iterator iterator = premiumPhone.keySet().iterator();while (iterator.hasNext()){System.out.println(premiumPhone.get(iterator.next()));premiumPhone.put("Sony", "Xperia Z");} } }

運行結(jié)果：

S5 HTC one iPhone

?

五、fail-fast 和 fail-safe 的區(qū)別：

?Fail Fast IteratorFail Safe Iterator

Throw ConcurrentModification Exception	Yes	No
Clone object	No	Yes
Memory Overhead	No	Yes
Examples	HashMap,Vector,ArrayList,HashSet	CopyOnWriteArrayList, ConcurrentHashMap

?

原文轉(zhuǎn)自：

https://blog.csdn.net/chenssy/article/details/38151189

https://blog.csdn.net/ch717828/article/details/46892051?utm_source=blogxgwz0

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的Java集合篇：fail-fast机制 与 fail-safe的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。