在 JDK 的 Collection 中我們時(shí)常會(huì)看到類似于這樣的話：
例如，ArrayList:
注意，迭代器的快速失敗行為無(wú)法得到保證，因?yàn)橐话銇?lái)說(shuō)，不可能對(duì)是否出現(xiàn)不同步并發(fā)修改做出任何硬性保證?？焖偈〉鲿?huì)盡最大努力拋出 ConcurrentModificationException。因此，為提高這類迭代器的正確性而編寫一個(gè)依賴于此異常的程序是錯(cuò)誤的做法：迭代器的快速失敗行為應(yīng)該僅用于檢測(cè) bug。
HashMap 中：
注意，迭代器的快速失敗行為不能得到保證，一般來(lái)說(shuō)，存在非同步的并發(fā)修改時(shí)，不可能作出任何堅(jiān)決的保證?？焖偈〉鞅M最大努力拋出 ConcurrentModificationException。因此，編寫依賴于此異常的程序的做法是錯(cuò)誤的，正確做法是：迭代器的快速失敗行為應(yīng)該僅用于檢測(cè)程序錯(cuò)誤。
在這兩段話中反復(fù)地提到”快速失敗”。那么何為”快速失敗”機(jī)制呢？
“快速失敗”也就是 fail-fast，它是 Java 集合的一種錯(cuò)誤檢測(cè)機(jī)制。當(dāng)多個(gè)線程對(duì)集合進(jìn)行結(jié)構(gòu)上的改變的操作時(shí)，有可能會(huì)產(chǎn)生 fail-fast 機(jī)制。記住是有可能，而不是一定。例如：假設(shè)存在兩個(gè)線程（線程 1、線程 2），線程 1 通過(guò) Iterator 在遍歷集合 A 中的元素，在某個(gè)時(shí)候線程 2 修改了集合 A 的結(jié)構(gòu)（是結(jié)構(gòu)上面的修改，而不是簡(jiǎn)單的修改集合元素的內(nèi)容），那么這個(gè)時(shí)候程序就會(huì)拋出 ConcurrentModificationException 異常，從而產(chǎn)生 fail-fast 機(jī)制。
public class FailFastTest {
private static List<Integer> list = new ArrayList<>();
/**
* @desc:線程one迭代list
* @Project:test
* @file:FailFastTest.java
* @Authro:chenssy
* @data:2014年7月26日
*/
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:當(dāng)i == 3時(shí)，修改list
* @Project:test
* @file:FailFastTest.java
* @Authro:chenssy
* @data:2014年7月26日
*/
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();
}
}
運(yùn)行結(jié)果：
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.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(Unknown Source)
at java.util.ArrayList$Itr.next(Unknown Source)
at test.ArrayListTest$threadOne.run(ArrayListTest.java:23)
通過(guò)上面的示例和講解，我初步知道 fail-fast 產(chǎn)生的原因就在于程序在對(duì) collection 進(jìn)行迭代時(shí)，某個(gè)線程對(duì)該 collection 在結(jié)構(gòu)上對(duì)其做了修改，這時(shí)迭代器就會(huì)拋出 ConcurrentModificationException 異常信息，從而產(chǎn)生 fail-fast。
要了解 fail-fast 機(jī)制，我們首先要對(duì) ConcurrentModificationException 異常有所了解。當(dāng)方法檢測(cè)到對(duì)象的并發(fā)修改，但不允許這種修改時(shí)就拋出該異常。同時(shí)需要注意的是，該異常不會(huì)始終指出對(duì)象已經(jīng)由不同線程并發(fā)修改，如果單線程違反了規(guī)則，同樣也有可能會(huì)拋出改異常。
誠(chéng)然，迭代器的快速失敗行為無(wú)法得到保證，它不能保證一定會(huì)出現(xiàn)該錯(cuò)誤，但是快速失敗操作會(huì)盡最大努力拋出 ConcurrentModificationException 異常，所以因此，為提高此類操作的正確性而編寫一個(gè)依賴于此異常的程序是錯(cuò)誤的做法，正確做法是：ConcurrentModificationException 應(yīng)該僅用于檢測(cè) bug。下面我將以 ArrayList 為例進(jìn)一步分析 fail-fast 產(chǎn)生的原因。
從前面我們知道 fail-fast 是在操作迭代器時(shí)產(chǎn)生的?，F(xiàn)在我們來(lái)看看 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() 方法時(shí)都是調(diào)用 checkForComodification() 方法，該方法主要就是檢測(cè) modCount == expectedModCount ? 若不等則拋出 ConcurrentModificationException 異常，從而產(chǎn)生 fail-fast 機(jī)制。所以要弄清楚為什么會(huì)產(chǎn)生 fail-fast 機(jī)制我們就必須要用弄明白為什么 modCount != expectedModCount ，他們的值在什么時(shí)候發(fā)生改變的。
expectedModCount 是在 Itr 中定義的：int expectedModCount = ArrayList.this.modCount;所以他的值是不可能會(huì)修改的，所以會(huì)變的就是 modCount。modCount 是在 AbstractList 中定義的，為全局變量：
protected transient int modCount = 0;
那么他什么時(shí)候因?yàn)槭裁丛蚨l(fā)生改變呢？請(qǐng)看 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;
}
else
for (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 中無(wú)論 add、remove、clear 方法只要是涉及了改變 ArrayList 元素的個(gè)數(shù)的方法都會(huì)導(dǎo)致 modCount 的改變。所以我們這里可以初步判斷由于 expectedModCount 得值與 modCount 的改變不同步，導(dǎo)致兩者之間不等從而產(chǎn)生 fail-fast 機(jī)制。知道產(chǎn)生 fail-fast 產(chǎn)生的根本原因了，我們可以有如下場(chǎng)景：
有兩個(gè)線程（線程 A，線程 B），其中線程 A 負(fù)責(zé)遍歷 list、線程B修改 list。線程 A 在遍歷 list 過(guò)程的某個(gè)時(shí)候（此時(shí) expectedModCount = modCount=N），線程啟動(dòng)，同時(shí)線程B增加一個(gè)元素，這是 modCount 的值發(fā)生改變（modCount + 1 = N + 1）。線程 A 繼續(xù)遍歷執(zhí)行 next 方法時(shí)，通告 checkForComodification 方法發(fā)現(xiàn) expectedModCount = N ，而 modCount = N + 1，兩者不等，這時(shí)就拋出ConcurrentModificationException 異常，從而產(chǎn)生 fail-fast 機(jī)制。
所以，直到這里我們已經(jīng)完全了解了 fail-fast 產(chǎn)生的根本原因了。知道了原因就好找解決辦法了。
通過(guò)前面的實(shí)例、源碼分析，我想各位已經(jīng)基本了解了 fail-fast 的機(jī)制，下面我就產(chǎn)生的原因提出解決方案。這里有兩種解決方案：
方案一：在遍歷過(guò)程中所有涉及到改變 modCount 值得地方全部加上 synchronized 或者直接使用 Collections.synchronizedList，這樣就可以解決。但是不推薦，因?yàn)樵鰟h造成的同步鎖可能會(huì)阻塞遍歷操作。
方案二：使用 CopyOnWriteArrayList 來(lái)替換 ArrayList。推薦使用該方案。
CopyOnWriteArrayList 為何物？ArrayList 的一個(gè)線程安全的變體，其中所有可變操作（add、set 等等）都是通過(guò)對(duì)底層數(shù)組進(jìn)行一次新的復(fù)制來(lái)實(shí)現(xiàn)的。 該類產(chǎn)生的開銷比較大，但是在兩種情況下，它非常適合使用。1：在不能或不想進(jìn)行同步遍歷，但又需要從并發(fā)線程中排除沖突時(shí)。2：當(dāng)遍歷操作的數(shù)量大大超過(guò)可變操作的數(shù)量時(shí)。遇到這兩種情況使用 CopyOnWriteArrayList 來(lái)替代 ArrayList 再適合不過(guò)了。那么為什么 CopyOnWriterArrayList 可以替代 ArrayList 呢？
第一、CopyOnWriterArrayList 的無(wú)論是從數(shù)據(jù)結(jié)構(gòu)、定義都和 ArrayList 一樣。它和 ArrayList 一樣，同樣是實(shí)現(xiàn) List 接口，底層使用數(shù)組實(shí)現(xiàn)。在方法上也包含 add、remove、clear、iterator 等方法。
第二、CopyOnWriterArrayList 根本就不會(huì)產(chǎn)生 ConcurrentModificationException 異常，也就是它使用迭代器完全不會(huì)產(chǎn)生 fail-fast 機(jī)制。請(qǐng)看：
private static class COWIterator<E> implements ListIterator<E> {
/** 省略此處代碼 */
public E next() {
if (!(hasNext()))
throw new NoSuchElementException();
return this.snapshot[(this.cursor++)];
}
/** 省略此處代碼 */
}
CopyOnWriterArrayList 的方法根本就沒(méi)有像 ArrayList 中使用 checkForComodification 方法來(lái)判斷 expectedModCount 與 modCount 是否相等。它為什么會(huì)這么做，憑什么可以這么做呢？我們以 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 方法有一個(gè)最大的不同點(diǎn)就在于，下面三句代碼：
Object[] arrayOfObject2 = Arrays.copyOf(arrayOfObject1, i + 1);
arrayOfObject2[i] = paramE;
setArray(arrayOfObject2);
就是這三句代碼使得 CopyOnWriterArrayList 不會(huì)拋 ConcurrentModificationException 異常。他們所展現(xiàn)的魅力就在于 copy 原來(lái)的 array，再在 copy 數(shù)組上進(jìn)行 add 操作，這樣做就完全不會(huì)影響 COWIterator 中的 array 了。
所以 CopyOnWriterArrayList 所代表的核心概念就是：任何對(duì) array 在結(jié)構(gòu)上有所改變的操作（add、remove、clear 等），CopyOnWriterArrayList 都會(huì) copy 現(xiàn)有的數(shù)據(jù)，再在 copy 的數(shù)據(jù)上修改，這樣就不會(huì)影響 COWIterator 中的數(shù)據(jù)了，修改完成之后改變?cè)袛?shù)據(jù)的引用即可。同時(shí)這樣造成的代價(jià)就是產(chǎn)生大量的對(duì)象，同時(shí)數(shù)組的 copy 也是相當(dāng)有損耗的。
掃碼關(guān)注鍍金池微信號(hào)
手機(jī)訂課，優(yōu)惠多多