ArrayList線程不安全怎么辦？

有三種解決方法：

使用對(duì)應(yīng)的 Vector 類(lèi)，這個(gè)類(lèi)中的所有方法都加上了 synchronized 關(guān)鍵字

• 就和 HashMap 和 HashTable 的關(guān)系一樣

使用 Collections 提供的 synchronizedList 方法，將一個(gè)原本線程不安全的集合類(lèi)轉(zhuǎn)換為線程安全的，使用方法如下：

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

其實(shí) HashMap 也可以用這招：

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

這個(gè)看上去有點(diǎn)東西，其實(shí)也是給每個(gè)方法加上一個(gè) synchronized，不過(guò)不是直接加在方法上，而是加在方法內(nèi)部，只有當(dāng)線程獲取到 mutex 這個(gè)對(duì)象的鎖，才能進(jìn)入代碼塊：

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

使用 JUC 包下提供的 CopyOnWriteArrayList 類(lèi)

• 其實(shí) ConcurrentHashMap 也是 JUC 包下的

這里具體討論一下 CopyOnWriteArrayList 這個(gè)類(lèi)，它采用了“寫(xiě)時(shí)復(fù)制”的技術(shù)，也就是說(shuō)，每當(dāng)要往這個(gè) list 中添加元素時(shí)，并不是直接就添加了，而是會(huì)先復(fù)制一份 list，然后在這個(gè)復(fù)制中添加元素，最后再修改指針的指向，看看 add 的源碼：

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

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

確實(shí)是這樣的，在寫(xiě)操作比較多的場(chǎng)景下，CopyOnWriteArrayList 確實(shí)比 Vector 還要慢，但它有兩個(gè)優(yōu)勢(shì)：

雖然寫(xiě)操作爛了，但讀操作快了很多，因?yàn)樵?vector 中，讀操作也是需要鎖的，而在這里，讀操作就不需要鎖了，get 方法比較短可能不便于理解，我們看看 indexOf 這個(gè)方法：

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)，這個(gè)方法先把當(dāng)前數(shù)組 array 交給了 es 這個(gè)變量，后續(xù)的所有操作都是基于 es 進(jìn)行的（此時(shí) array 和 es 都指向內(nèi)存中的同一份數(shù)組 a1）

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

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

在 forEach 遍歷一個(gè) vector 時(shí)，是不允許對(duì) vector 進(jìn)行修改的，會(huì)報(bào)出 ConcurrentModificationException 這個(gè)異常，理由很簡(jiǎn)單，因?yàn)橹挥幸环輸?shù)組，要是遍歷到一半有其它線程把數(shù)組清空了不就出問(wèn)題了嗎，因此 java 干脆就直接禁止這種遍歷時(shí)修改數(shù)組的行為了，但對(duì)于 CopyOnWriteArrayList 來(lái)說(shuō)，它的遍歷是一直在 a1 上進(jìn)行的，其它寫(xiě)線程只能修改到 a2，這對(duì) a1 是沒(méi)有任何影響的，我們看一段代碼來(lái)驗(yàn)證一下：

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í)把數(shù)組清空
        for (Integer i : list) {
            System.out.println(i);
            list.clear();
        }
    }
}

結(jié)果是沒(méi)有報(bào)錯(cuò)，并且完整輸出了 0~999 所有的數(shù)字，可見(jiàn)這里遍歷的就是最開(kāi)始的那個(gè)數(shù)組 a1，期間哪怕有再多的寫(xiě)操作也不會(huì)影響到 a1，因?yàn)樗械膶?xiě)操作都是在 a2 a3 a4 上進(jìn)行的
綜上所述，CopyOnWriteArrayList 的優(yōu)點(diǎn)有兩個(gè)：

• 讀操作不需要鎖，因此讀讀可以并發(fā)，讀寫(xiě)也能并發(fā)，性能較好
• forEach 遍歷時(shí)也不需要鎖（其實(shí)遍歷也算是一種讀操作吧），主要是遍歷時(shí)數(shù)組可以被修改，不會(huì)報(bào)錯(cuò)（因?yàn)楸闅v的是 a1，改的是 a2 a3，對(duì) a1 不會(huì)有影響）

但它的缺點(diǎn)也很明顯，主要有兩點(diǎn)：

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

可以發(fā)現(xiàn)一個(gè)有趣的事情，就是成也舊數(shù)組，敗也舊數(shù)組，正因?yàn)樗凶x取都是基于舊數(shù)組 a1 的，因此可以不加鎖就大膽進(jìn)行，不怕有線程把數(shù)組改了，因?yàn)楦膭?dòng)都是在 a2 a3 上的，跟 a1 沒(méi)有關(guān)系，但也正因?yàn)樗凶x取都是基于舊數(shù)組 a1 的，因此一旦讀取操作開(kāi)始，就算有線程在數(shù)組中加入了一個(gè)很重要的數(shù)據(jù)，這個(gè)讀取操作也是感知不到這個(gè)最新的數(shù)據(jù)的，因?yàn)檫@個(gè)最新的數(shù)據(jù)只會(huì)在 a2 中有

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

最新評(píng)論