老生常談java中的fail-fast機(jī)制

在JDK的Collection中我們時(shí)常會(huì)看到類似于這樣的話：

例如，ArrayList：

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

HashMap中：

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

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

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

一、fail-fast示例

public class FailFastTest { 
 private static List<Integer> list = new ArrayList<>(); 
  
 /** 
  * @desc:線程one迭代list 
  * @Project:test 
  * @file:FailFastTest.java 
  * @Authro:chenssy 

  */ 
 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) 

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

通過上面的示例和講解，我初步知道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)方法檢測到對(duì)象的并發(fā)修改，但不允許這種修改時(shí)就拋出該異常。同時(shí)需要注意的是，該異常不會(huì)始終指出對(duì)象已經(jīng)由不同線程并發(fā)修改，如果單線程違反了規(guī)則，同樣也有可能會(huì)拋出改異常。

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

從前面我們知道fail-fast是在操作迭代器時(shí)產(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()方法時(shí)都是調(diào)用checkForComodification()方法，該方法主要就是檢測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 
 /** 省略此處代碼 */ 
} 
 
ublic 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中無論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)生的根本原因了，我們可以有如下場景：

有兩個(gè)線程（線程A，線程B），其中線程A負(fù)責(zé)遍歷list、線程B修改list。線程A在遍歷list過程的某個(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)生的根本原因了。知道了原因就好找解決辦法了。

三、fail-fast解決辦法

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

方案一：在遍歷過程中所有涉及到改變modCount值得地方全部加上synchronized或者直接使用Collections.synchronizedList，這樣就可以解決。但是不推薦，因?yàn)樵鰟h造成的同步鎖可能會(huì)阻塞遍歷操作。

方案二：使用CopyOnWriteArrayList來替換ArrayList。推薦使用該方案。

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

第一、CopyOnWriterArrayList的無論是從數(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的方法根本就沒有像ArrayList中使用checkForComodification方法來判斷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原來的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ù)了，修改完成之后改變原有數(shù)據(jù)的引用即可。同時(shí)這樣造成的代價(jià)就是產(chǎn)生大量的對(duì)象，同時(shí)數(shù)組的copy也是相當(dāng)有損耗的。

以上這篇老生常談java中的fail-fast機(jī)制就是小編分享給大家的全部內(nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持億速云。