ArrayList線程不安全怎么辦？

有三種解決方法：

使用對應的 Vector 類，這個類中的所有方法都加上了 synchronized 關鍵字

• 就和 HashMap 和 HashTable 的關系一樣

使用 Collections 提供的 synchronizedList 方法，將一個原本線程不安全的集合類轉換為線程安全的，使用方法如下：

List<Integer> list = Collections.synchronizedList(new ArrayList<>());

其實 HashMap 也可以用這招：

Map<String, String> map = Collections.synchronizedMap(new HashMap<>());

這個看上去有點東西，其實也是給每個方法加上一個 synchronized，不過不是直接加在方法上，而是加在方法內部，只有當線程獲取到 mutex 這個對象的鎖，才能進入代碼塊：

public E get(int index) {
    synchronized (mutex) {
        return list.get(index);
    }
}

使用 JUC 包下提供的 CopyOnWriteArrayList 類

• 其實 ConcurrentHashMap 也是 JUC 包下的

這里具體討論一下 CopyOnWriteArrayList 這個類，它采用了“寫時復制”的技術，也就是說，每當要往這個 list 中添加元素時，并不是直接就添加了，而是會先復制一份 list，然后在這個復制中添加元素，最后再修改指針的指向，看看 add 的源碼：

public boolean add(E e) {
    synchronized (lock) {
        //得到當前的數(shù)組
        Object[] es = getArray();
        int len = es.length;
        //復制一份并擴容
        es = Arrays.copyOf(es, len + 1);
        //把新元素添加進去
        es[len] = e;
        //修改指針的指向
        setArray(es);
        return true;
    }
}

有人可能會疑惑，這有什么意義，這不也加了 synchronized 嗎，而且還要復制數(shù)組，這**不是比 Vector 還要爛嗎？

確實是這樣的，在寫操作比較多的場景下，CopyOnWriteArrayList 確實比 Vector 還要慢，但它有兩個優(yōu)勢：

雖然寫操作爛了，但讀操作快了很多，因為在 vector 中，讀操作也是需要鎖的，而在這里，讀操作就不需要鎖了，get 方法比較短可能不便于理解，我們看看 indexOf 這個方法：

public int indexOf(Object o) {
    Object[] es = getArray();
    return indexOfRange(o, es, 0, es.length);
}
private static int indexOfRange(Object o, Object[] es, int from, int to) {
    if (o == null) {
        for (int i = from; i < to; i++)
            if (es[i] == null)
                return i;
    } else {
        //****here****
        for (int i = from; i < to; i++)
            if (o.equals(es[i]))
                return i;
    }
    return -1;
}

可以發(fā)現(xiàn)，這個方法先把當前數(shù)組 array 交給了 es 這個變量，后續(xù)的所有操作都是基于 es 進行的（此時 array 和 es 都指向內存中的同一份數(shù)組 a1）

由于所有寫操作都是在 a1 的拷貝上進行的（我們把內存中的這份拷貝稱為 a2），因此不會影響到那些正在 a1 上進行的讀操作，并且就算寫操作執(zhí)行完畢了，array 指向了 a2，也不會影響到 es 這個數(shù)組，因為 es 指向的還是 a1

試想，如果 vector 的讀操作不加鎖會出現(xiàn)什么情況？由于 vector 中所有的讀寫操作都是基于同一個數(shù)組的，因此雖然讀操作一開始拿到的數(shù)組是沒問題的，但在后續(xù)遍歷的過程中（比如上面代碼標注了 here 的地方），很可能出現(xiàn)其他線程對數(shù)組進行了修改，夸張點說，如果有個線程把數(shù)組給清空了，那么讀操作就肯定會報錯了，而對于 CopyOnWriteArrayList 來說，就算有清空的操作，那也是在 a2 上進行的，而讀操作還是在 a1 上進行，不會有任何影響

在 forEach 遍歷一個 vector 時，是不允許對 vector 進行修改的，會報出 ConcurrentModificationException 這個異常，理由很簡單，因為只有一份數(shù)組，要是遍歷到一半有其它線程把數(shù)組清空了不就出問題了嗎，因此 java 干脆就直接禁止這種遍歷時修改數(shù)組的行為了，但對于 CopyOnWriteArrayList 來說，它的遍歷是一直在 a1 上進行的，其它寫線程只能修改到 a2，這對 a1 是沒有任何影響的，我們看一段代碼來驗證一下：

public class Test {
    public static void main(String[] args) {
        CopyOnWriteArrayList<Integer> list = new CopyOnWriteArrayList<>();
        for (int i = 0; i < 1000; i++) {
            list.add(i);
        }
        //遍歷時把數(shù)組清空
        for (Integer i : list) {
            System.out.println(i);
            list.clear();
        }
    }
}

結果是沒有報錯，并且完整輸出了 0~999 所有的數(shù)字，可見這里遍歷的就是最開始的那個數(shù)組 a1，期間哪怕有再多的寫操作也不會影響到 a1，因為所有的寫操作都是在 a2 a3 a4 上進行的
綜上所述，CopyOnWriteArrayList 的優(yōu)點有兩個：

• 讀操作不需要鎖，因此讀讀可以并發(fā)，讀寫也能并發(fā)，性能較好
• forEach 遍歷時也不需要鎖（其實遍歷也算是一種讀操作吧），主要是遍歷時數(shù)組可以被修改，不會報錯（因為遍歷的是 a1，改的是 a2 a3，對 a1 不會有影響）

但它的缺點也很明顯，主要有兩點：

• 首先，寫操作的內存消耗非常大，每次修改數(shù)組都會進行一次拷貝，如果數(shù)組比較大或者修改次數(shù)比較多，很快就會消耗掉大量內存，觸發(fā) GC，因此在寫多的場景下一定要慎用這個類
• 其次，所有讀操作和 forEach 遍歷都是基于舊數(shù)組 a1 的，就算遍歷途中新增了一個很重要的數(shù)據(jù)，這個數(shù)據(jù)也是在 a2 中，遍歷 a1 是無法得到這個數(shù)據(jù)的，總之就是，所有的讀操作一旦開始，就無法再感知到最新的那些數(shù)據(jù)

可以發(fā)現(xiàn)一個有趣的事情，就是成也舊數(shù)組，敗也舊數(shù)組，正因為所有讀取都是基于舊數(shù)組 a1 的，因此可以不加鎖就大膽進行，不怕有線程把數(shù)組改了，因為改動都是在 a2 a3 上的，跟 a1 沒有關系，但也正因為所有讀取都是基于舊數(shù)組 a1 的，因此一旦讀取操作開始，就算有線程在數(shù)組中加入了一個很重要的數(shù)據(jù)，這個讀取操作也是感知不到這個最新的數(shù)據(jù)的，因為這個最新的數(shù)據(jù)只會在 a2 中有

到此這篇關于淺談Java中ArrayList線程不安全怎么辦的文章就介紹到這了,更多相關ArrayList線程不安全內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論