這篇文章主要介紹了java中fail-fast示例，具有一定借鑒價(jià)值，需要的朋友可以參考下。希望大家閱讀完這篇文章后大有收獲。下面讓小編帶著大家一起了解一下。

成都創(chuàng)新互聯(lián)公司是一個技術(shù)型專業(yè)的建站公司,致力于為廣大企業(yè)、創(chuàng)業(yè)者打造切實(shí)有效的PC站、WAP站、APP站點(diǎn)等企業(yè)網(wǎng)站。無論是企業(yè)宣傳的成都營銷網(wǎng)站建設(shè)、致力于營銷的電商網(wǎng)站、內(nèi)容資訊分享的各行業(yè)網(wǎng)站或其他類型網(wǎng)站,我們都從網(wǎng)站前期定位分析策劃、技術(shù)架構(gòu),到網(wǎng)站界面設(shè)計(jì)、創(chuàng)意表現(xiàn)、站點(diǎn)架構(gòu)搭建以及后續(xù)訪問監(jiān)控、維護(hù)、網(wǎng)站托管運(yùn)營反饋建議等提供整套服務(wù)。

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

例如，ArrayList:

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

HashMap中：

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

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

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

一、fail-fast示例

public class FailFastTest {
    private static List 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 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)生的原因就在于程序在對 collection 進(jìn)行迭代時(shí)，某個線程對該 collection 在結(jié)構(gòu)上對其做了修改，這時(shí)迭代器就會拋出 ConcurrentModificationException 異常信息，從而產(chǎn)生 fail-fast。

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

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

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

private class Itr implements Iterator {
        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ī)制。所以要弄清楚為什么會產(chǎn)生fail-fast機(jī)制我們就必須要用弄明白為什么modCount != expectedModCount ，他們的值在什么時(shí)候發(fā)生改變的。

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

 protected transient int modCount = 0;

那么他什么時(shí)候因?yàn)槭裁丛蚨l(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;
        }
    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元素的個數(shù)的方法都會導(dǎo)致modCount的改變。所以我們這里可以初步判斷由于expectedModCount 得值與modCount的改變不同步，導(dǎo)致兩者之間不等從而產(chǎn)生fail-fast機(jī)制。知道產(chǎn)生fail-fast產(chǎn)生的根本原因了，我們可以有如下場景：

有兩個線程（線程A，線程B），其中線程A負(fù)責(zé)遍歷list、線程B修改list。線程A在遍歷list過程的某個時(shí)候（此時(shí)expectedModCount = modCount=N），線程啟動，同時(shí)線程B增加一個元素，這是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造成的同步鎖可能會阻塞遍歷操作。

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

以上就是fail-fast機(jī)制的詳細(xì)內(nèi)容，更多請關(guān)注創(chuàng)新互聯(lián)其它相關(guān)文章！

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享java中fail-fast示例內(nèi)容對大家有幫助，同時(shí)也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，遇到問題就找創(chuàng)新互聯(lián)，詳細(xì)的解決方法等著你來學(xué)習(xí)!