java的各種集合為什麼不安全（List、Set、Map）以及代替方案

Life_Goes_On發表於2020-10-14

我們已經知道多執行緒下會有各種不安全的問題，都知道併發的基本解決方案，這裡對出現錯誤的情況進行一個實際模擬，以此能夠聯想到具體的生產環境中。

一、List 的不安全

1.1 問題

看一段程式碼：

public static void main(String[] args) {
    ArrayList<String> list = new ArrayList<>();

    for (int i = 0; i < 3; i++){
        new Thread(()->{
            list.add(UUID.randomUUID().toString().substring(0,8));
            System.out.println(list);
        },String.valueOf(i)).start();
    }
}

過程很簡單，只有 3 個執行緒而已，對同一個 list 進行 add 的寫操作，並隨後進行輸出的讀操作。

輸出結果，多執行幾次，驚喜多多。

那麼，情況不嚴重的時候，這裡顯然還正常執行結束了，只是導致了還沒來得及寫的時候，就已經讀出了資料。

如果把執行緒數增加試試，可能還會看到這樣的奇觀：

報錯了：重點異常：java.util.ConcurrentModificationException，翻譯過來就是併發修改異常。

1.2 產生原因

普通的 ArrayList 集合裡面沒有任何特殊處理，在多執行緒情況下，他們可以共同進行訪問。

那麼在多執行緒同時操作的時候，按照操作的情況就有這幾種：

各個執行緒都讀。不影響，前提是隻有讀；
各個執行緒都寫。會出現問題，這裡的點有兩種情況：
1. 值覆蓋問題，因為 ArrayList 的底層陣列，寫入值的時候要先計算到一個下標位置，然後給對應的位置去賦值，多執行緒就會出現值覆蓋的問題；
2. 空指標異常，因為 ArrayList 的底層陣列，寫入值在陣列滿的時候需要擴容，在擴容還沒完成的時候，新的下標卻已經計算出來並且要去插入，那麼就會出現空指標異常。
有的讀有的寫。那麼顯然對於多個執行緒來說，2 裡面各個執行緒寫的情況對應的問題就會出現。除此之外：
1. 如果多執行緒有的讀有的寫，對於 ArrayList 底層，某些情況下，物件是不允許進行修改的，如果修改了，後面呼叫某些方法時，就會檢測到，然後就直接丟擲ConcurrentModificationException。
2. 具體一下，因為原始碼裡，寫操作對集合修改是寫，而next、remove等 Itr 的遍歷讀操作的時候會通過當前集合的修改次數與 Itr 物件建立時記錄的次數校驗集合是否被修改，如果修改了，不一致就說明正讀的時候還有別的執行緒在改，就會丟擲異常。
3. JDK作者說了，會拋這個異常的都叫fail-fast iterator。

第 3 種情況就是對應了我們上面的程式碼線上程多起來的情況，因為輸出 list 的時候需要遍歷的讀，而此時還有別的執行緒在進行 add 的修改操作。

1.3 解決方法

注意：當然不能自己加鎖，因為集合類已經再演變過程有執行緒安全的替代品，自己的程式碼加鎖的粒度已經在集合的外層再加一層了，粒度太大。

同樣能夠完成 ArrayList 功能的，可以使用 Vector，檢視原始碼就會發現，Vector 的基本結構是一個叫 elementData 的 Object 型別的陣列，和 ArrayList 類似，但是對應的操作方法，基本都加上了 synchronized 關鍵字，因此它是執行緒安全的集合。
資料量小的時候，使用 Collections.synchronizedList(new ArrayList())這種方式，來包裹這個集合，跟 Collections 裡面 synchronizedMap包裹hashmap 是一樣的，更多的，還有：

顯然能傳入引數的這些基本集合類都是執行緒不安全的。

第三種就是，直接使用 juc 包裡面的，CopyOnWriteArrayList() 類，這個類就是併發包給我們提供的執行緒安全的列表類。1.4裡介紹了這個集合。

1.4 CopyOnWriteArrayList

對於 CopyOnWriteArrayList 類，名字上就可以聽的出來，寫時複製的列表。

首先，按照前面的我們的分析，只要涉及了寫的操作，和讀或者寫搭配的多執行緒情況，就會出現問題，那麼多執行緒同時讀卻不會出現問題，因此相比較於直接都加上 synchronized 的方式，他的思想就是：讀寫分離。這個思想在資料庫對於高併發的架構層面也有一樣的設計。

這樣一來，對於這個 List 集合來說，分為不同操作的保證執行緒安全的策略，就能夠保證更好的效能。

寫的方法，我們首先可以看 add 方法原始碼：

步驟很清楚，如果有了寫操作，需要加鎖：

加鎖
獲取到當前的集合陣列；
計算長度；
呼叫 Arrays.copyOf 方法進行新增操作，每次只新增一個元素進去；
修改引用，更新最新的集合；
return true。
解鎖

其中的 lock 在原始碼裡就是一個：

可以看到是一個普通的 Object。

那麼加鎖的時候就用 synchronized 對 Object 進行加鎖，沒有采用 juc 的 ReetrantLock，註釋li也寫了，偏向於使用內建的 monitor 也就是 synchronized 底層 monitor 鎖，這一點也充分說明了 synchronized 的效能更新使得原始碼作者使用它。

這個方法是處理最直接的，其他對應的寫操作：remove、set等等也是一樣的基礎流程。

我們再來看看讀操作 get 方法：

二、HashSet 的不安全

2.1 問題及原因

我們還是用 List 一樣的測試程式碼；

public class TestSet {
    public static void main(String[] args) {
        HashSet<String> set = new HashSet<>();
        for (int i = 0; i < 100; i++){
            new Thread(()->{
                set.add(UUID.randomUUID().toString().substring(0,8));
                System.out.println(set);
            },String.valueOf(i)).start();
        }
    }
}

就會看到一樣的錯誤：

2.2 出現問題的原因

其實從出現 ConcurrentModificationException 異常來看，我們可以猜測是和 List 類似的原因導致的異常。

可以看到，原始碼裡面，Set 的底層維護的是一個 HashMap 來實現。對於遍歷操作來說，都是一樣的使用了 fail-fast iterator 迭代器，因此會出現這個異常。

另外，因為 HashSet 的底層是 HashMap ，本質上，對於每一個 key ，保證唯一，使用了一個 value 為 PRESENT 常量的鍵值對進行儲存。

put 的過程也是呼叫 map 的 put 方法。

2.3 解決方案

List 有對應的 Vector 可用，本來就是執行緒安全的集合，但是 Set 沒有；
資料量小的時候，使用 Collections.synchronizedSet(new HashSet<>()) 這種方式，來包裹這個集合，上面我們使用 List 的時候也有類似的方法；
同樣的，juc包為我們提供了新的執行緒安全集合 CopyOnWriteArraySet()。

2.4 CopyOnWriteArraySet

按照前面的思路，List 的對應執行緒安全集合是在 List 集合的陣列基礎上進行加鎖的相關操作。
那麼 Set 既然底層是 HashMap，對應的執行緒安全集合就應該是對 HashMap 的執行緒安全集合進行加鎖，或者說直接用 ConcurrentHashMap 集合來實現 CopyOnWriteArraySet 。
但事實上，原始碼並不是這麼做的。

從名字來看，和 ConcurrentHashMap 也沒有什麼關係，而是類似 CopyOnWriteArrayList 的命名，說明是讀寫單獨處理，來讓他成為執行緒安全的集合，那為什麼是 ArraySet 多一個 array 修飾語呢？

可以看到，他的思路沒有順延 util 包的 HashSet 的實現思路，而是直接使用了 CopyOnWriteArrayList 作為底層資料結構。也就是說沒有利用 Map 的鍵值對對映的特性來保證 set 的唯一性，而是用一個陣列為基底的列表來實現。（那顯然在去重方面就要做額外的操作了。）

然後每一個實現的方法都很簡單，基本是直接呼叫了 CopyOnWriteArrayList 的方法：