一不當心就讓Java開發踩坑的fail-fast是個什麼鬼？

GitHub 2.1k Star 的Java工程師成神之路 ，不來了解一下嗎?

GitHub 2.1k Star 的Java工程師成神之路 ，真的不來了解一下嗎?

GitHub 2.1k Star 的Java工程師成神之路 ，真的肯定不來了解一下嗎?

我在《爲何阿里巴巴禁止在 foreach 循環裏進行元素的 remove/add 操做》一文中曾經介紹過Java中的fail-fast機制，可是並無深刻介紹，本文，就來深刻介紹一下fail-fast。

什麼是fail-fast

首先咱們看下維基百科中關於fail-fast的解釋：

In systems design, a fail-fast system is one which immediately reports at its interface any condition that is likely to indicate a failure. Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process. Such designs often check the system's state at several points in an operation, so any failures can be detected early. The responsibility of a fail-fast module is detecting errors, then letting the next-highest level of the system handle them.

大概意思是：在系統設計中，快速失效系統一種能夠當即報告任何可能代表故障的狀況的系統。快速失效系統一般設計用於中止正常操做，而不是試圖繼續可能存在缺陷的過程。這種設計一般會在操做中的多個點檢查系統的狀態，所以能夠及早檢測到任何故障。快速失敗模塊的職責是檢測錯誤，而後讓系統的下一個最高級別處理錯誤。

其實，這是一種理念，說白了就是在作系統設計的時候先考慮異常狀況，一旦發生異常，直接中止並上報。

舉一個最簡單的fail-fast的例子：

public int divide(int divisor,int dividend){
    if(dividend == 0){
        throw new RuntimeException("dividend can't be null");
    }
    return divisor/dividend;
}
複製代碼

上面的代碼是一個對兩個整數作除法的方法，在divide方法中，咱們對被除數作了個簡單的檢查，若是其值爲0，那麼就直接拋出一個異常，並明確提示異常緣由。這其實就是fail-fast理念的實際應用。

這樣作的好處就是能夠預先識別出一些錯誤狀況，一方面能夠避免執行復雜的其餘代碼，另一方面，這種異常狀況被識別以後也能夠針對性的作一些單獨處理。

怎麼樣，如今你知道fail-fast了吧，其實他並不神祕，你平常的代碼中可能常常會在使用的。

既然，fail-fast是一種比較好的機制，爲何文章標題說fail-fast會有坑呢？

緣由是Java的集合類中運用了fail-fast機制進行設計，一旦使用不當，觸發fail-fast機制設計的代碼，就會發生非預期狀況。

集合類中的fail-fast

咱們一般說的Java中的fail-fast機制，默認指的是Java集合的一種錯誤檢測機制。當多個線程對部分集合進行結構上的改變的操做時，有可能會產生fail-fast機制，這個時候就會拋出ConcurrentModificationException（後文用CME代替）。

CMException，當方法檢測到對象的併發修改，但不容許這種修改時就拋出該異常。

不少時候正是由於代碼中拋出了CMException，不少程序員就會很困惑，明明本身的代碼並無在多線程環境中執行，爲何會拋出這種併發有關的異常呢？這種狀況在什麼狀況下才會拋出呢？咱們就來深刻分析一下。

異常復現

在Java中， 若是在foreach 循環裏對某些集合元素進行元素的 remove/add 操做的時候，就會觸發fail-fast機制，進而拋出CMException。

如如下代碼：

List<String> userNames = new ArrayList<String>() {{
    add("Hollis");
    add("hollis");
    add("HollisChuang");
    add("H");
}};

for (String userName : userNames) {
    if (userName.equals("Hollis")) {
        userNames.remove(userName);
    }
}

System.out.println(userNames);
複製代碼

以上代碼，使用加強for循環遍歷元素，並嘗試刪除其中的Hollis字符串元素。運行以上代碼，會拋出如下異常：

Exception in thread "main" java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
at java.util.ArrayList$Itr.next(ArrayList.java:859)
at com.hollis.ForEach.main(ForEach.java:22)
複製代碼

一樣的，讀者能夠嘗試下在加強for循環中使用add方法添加元素，結果也會一樣拋出該異常。

在深刻原理以前，咱們先嚐試把foreach進行解語法糖，看一下foreach具體如何實現的。

咱們使用jad工具，對編譯後的class進行反編譯，獲得如下代碼：

public static void main(String[] args) {
    // 使用ImmutableList初始化一個List
    List<String> userNames = new ArrayList<String>() {{
        add("Hollis");
        add("hollis");
        add("HollisChuang");
        add("H");
    }};

    Iterator iterator = userNames.iterator();
    do
    {
        if(!iterator.hasNext())
            break;
        String userName = (String)iterator.next();
        if(userName.equals("Hollis"))
            userNames.remove(userName);
    } while(true);
    System.out.println(userNames);
}
複製代碼

能夠發現，foreach實際上是依賴了while循環和Iterator實現的。

異常原理

經過以上代碼的異常堆棧，咱們能夠跟蹤到真正拋出異常的代碼是：

java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
複製代碼

該方法是在iterator.next()方法中調用的。咱們看下該方法的實現：

final void checkForComodification() {
    if (modCount != expectedModCount)
        throw new ConcurrentModificationException();
}
複製代碼

如上，在該方法中對modCount和expectedModCount進行了比較，若是兩者不想等，則拋出CMException。

那麼，modCount和expectedModCount是什麼？是什麼緣由致使他們的值不想等的呢？

modCount是ArrayList中的一個成員變量。它表示該集合實際被修改的次數。

List<String> userNames = new ArrayList<String>() {{
    add("Hollis");
    add("hollis");
    add("HollisChuang");
    add("H");
}};
複製代碼

當使用以上代碼初始化集合以後該變量就有了。初始值爲0。

expectedModCount 是 ArrayList中的一個內部類——Itr中的成員變量。

Iterator iterator = userNames.iterator();
複製代碼

以上代碼，便可獲得一個 Itr類，該類實現了Iterator接口。

expectedModCount表示這個迭代器預期該集合被修改的次數。其值隨着Itr被建立而初始化。只有經過迭代器對集合進行操做，該值纔會改變。

那麼，接着咱們看下userNames.remove(userName);方法裏面作了什麼事情，爲何會致使expectedModCount和modCount的值不同。

經過翻閱代碼，咱們也能夠發現，remove方法核心邏輯以下：

private void fastRemove(int index) {
    modCount++;
    int numMoved = size - index - 1;
    if (numMoved > 0)
        System.arraycopy(elementData, index+1, elementData, index,
                         numMoved);
    elementData[--size] = null; // clear to let GC do its work
}
複製代碼

能夠看到，它只修改了modCount，並無對expectedModCount作任何操做。

簡單畫一張圖描述下以上場景：



簡單總結一下，之因此會拋出CMException異常，是由於咱們的代碼中使用了加強for循環，而在加強for循環中，集合遍歷是經過iterator進行的，可是元素的add/remove倒是直接使用的集合類本身的方法。這就致使iterator在遍歷的時候，會發現有一個元素在本身不知不覺的狀況下就被刪除/添加了，就會拋出一個異常，用來提示用戶，可能發生了併發修改！

因此，在使用Java的集合類的時候，若是發生CMException，優先考慮fail-fast有關的狀況，實際上這裏並無真的發生併發，只是Iterator使用了fail-fast的保護機制，只要他發現有某一次修改是未通過本身進行的，那麼就會拋出異常。

關於如何解決這種問題，咱們在《爲何阿里巴巴禁止在 foreach 循環裏進行元素的 remove/add 操做》中介紹過，這裏再也不贅述了。

fail-safe

爲了不觸發fail-fast機制，致使異常，咱們可使用Java中提供的一些採用了fail-safe機制的集合類。

這樣的集合容器在遍歷時不是直接在集合內容上訪問的，而是先複製原有集合內容，在拷貝的集合上進行遍歷。

java.util.concurrent包下的容器都是fail-safe的，能夠在多線程下併發使用，併發修改。同時也能夠在foreach中進行add/remove 。

咱們拿CopyOnWriteArrayList這個fail-safe的集合類來簡單分析一下。

public static void main(String[] args) {
    List<String> userNames = new CopyOnWriteArrayList<String>() {{
        add("Hollis");
        add("hollis");
        add("HollisChuang");
        add("H");
    }};

    userNames.iterator();

    for (String userName : userNames) {
        if (userName.equals("Hollis")) {
            userNames.remove(userName);
        }
    }

    System.out.println(userNames);
}
複製代碼

以上代碼，使用CopyOnWriteArrayList代替了ArrayList，就不會發生異常。

fail-safe集合的全部對集合的修改都是先拷貝一份副本，而後在副本集合上進行的，並非直接對原集合進行修改。而且這些修改方法，如add/remove都是經過加鎖來控制併發的。

因此，CopyOnWriteArrayList中的迭代器在迭代的過程當中不須要作fail-fast的併發檢測。（由於fail-fast的主要目的就是識別併發，而後經過異常的方式通知用戶）

可是，雖然基於拷貝內容的優勢是避免了ConcurrentModificationException，但一樣地，迭代器並不能訪問到修改後的內容。如如下代碼：

public static void main(String[] args) {
    List<String> userNames = new CopyOnWriteArrayList<String>() {{
        add("Hollis");
        add("hollis");
        add("HollisChuang");
        add("H");
    }};

    Iterator it = userNames.iterator();

    for (String userName : userNames) {
        if (userName.equals("Hollis")) {
            userNames.remove(userName);
        }
    }

    System.out.println(userNames);

    while(it.hasNext()){
        System.out.println(it.next());
    }
}
複製代碼

咱們獲得CopyOnWriteArrayList的Iterator以後，經過for循環直接刪除原數組中的值，最後在結尾處輸出Iterator，結果發現內容以下：

[hollis, HollisChuang, H]
Hollis
hollis
HollisChuang
H
複製代碼

迭代器遍歷的是開始遍歷那一刻拿到的集合拷貝，在遍歷期間原集合發生的修改迭代器是不知道的。

Copy-On-Write

在瞭解了CopyOnWriteArrayList以後，不知道你們會不會有這樣的疑問：他的add/remove等方法都已經加鎖了，還要copy一份再修改幹嗎？畫蛇添足？一樣是線程安全的集合，這玩意和Vector有啥區別呢？

Copy-On-Write簡稱COW，是一種用於程序設計中的優化策略。其基本思路是，從一開始你們都在共享同一個內容，當某我的想要修改這個內容的時候，纔會真正把內容Copy出去造成一個新的內容而後再改，這是一種延時懶惰策略。

CopyOnWrite容器即寫時複製的容器。通俗的理解是當咱們往一個容器添加元素的時候，不直接往當前容器添加，而是先將當前容器進行Copy，複製出一個新的容器，而後新的容器裏添加元素，添加完元素以後，再將原容器的引用指向新的容器。

CopyOnWriteArrayList中add/remove等寫方法是須要加鎖的，目的是爲了不Copy出N個副本出來，致使併發寫。

可是，CopyOnWriteArrayList中的讀方法是沒有加鎖的。

public E get(int index) {
    return get(getArray(), index);
}
複製代碼

這樣作的好處是咱們能夠對CopyOnWrite容器進行併發的讀，固然，這裏讀到的數據可能不是最新的。由於寫時複製的思想是經過延時更新的策略來實現數據的最終一致性的，並不是強一致性。

**因此CopyOnWrite容器是一種讀寫分離的思想，讀和寫不一樣的容器。**而Vector在讀寫的時候使用同一個容器，讀寫互斥，同時只能作一件事兒。