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

阿新 • • 發佈：2020-10-14

我們已經知道多執行緒下會有各種不安全的問題，都知道併發的基本解決方案，這裡對出現錯誤的情況進行一個實際模擬，以此能夠聯想到具體的生產環境中。
# 一、List 的不安全
## 1.1 問題
看一段程式碼： ```java public static void main(String[] args) { ArrayList 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. **各個執行緒都讀**。不影響，前提是隻有讀； 2. **各個執行緒都寫**。會出現問題，這裡的點有兩種情況： 1. 值覆蓋問題，因為 ArrayList 的底層陣列，寫入值的時候要先計算到一個下標位置，然後給對應的位置去賦值，多執行緒就會出現值覆蓋的問題； 2. 空指標異常，因為 ArrayList 的底層陣列，寫入值在陣列滿的時候需要擴容，在擴容還沒完成的時候，新的下標卻已經計算出來並且要去插入，那麼就會出現空指標異常。 3. **有的讀有的寫**。那麼顯然對於多個執行緒來說，**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 方法原始碼：

步驟很清楚，如果有了**寫操作**，需要加鎖： 1. **加鎖** 2. 獲取到當前的集合陣列； 3. 計算長度； 4. 呼叫 Arrays.copyOf 方法進行**新增操作**，每次只新增一個元素進去； 5. 修改引用，更新最新的集合； 6. return true。 7. **解鎖** 其中的 lock 在原始碼裡就是一個：

可以看到是一個普通的 Object。那麼加鎖的時候就用 synchronized 對 Object 進行加鎖，沒有采用 juc 的 ReetrantLock，註釋li也寫了，**偏向於**使用內建的 monitor 也就是 synchronized 底層 monitor 鎖，這一點也充分說明了 synchronized 的效能更新使得原始碼作者使用它。這個方法是處理最直接的，其他對應的寫操作：remove、set等等也是一樣的基礎流程。我們再來看看**讀操作** get 方法：

# 二、HashSet 的不安全
## 2.1 問題及原因
我們還是用 List 一樣的測試程式碼； ```java public class TestSet { public static void main(String[] args) { HashSet 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
1. 按照前面的思路，List 的對應執行緒安全集合是在 List 集合的陣列基礎上進行加鎖的相關操作。 2. 那麼 Set 既然底層是 HashMap，對應的執行緒安全集合就應該是對 HashMap 的執行緒安全集合進行加鎖，或者說直接用 ConcurrentHashMap 集合來實現 CopyOnWriteArraySet 。 3. 但事實上，原始碼**並不是這麼做的**。從名字來看，和 ConcurrentHashMap 也沒有什麼關係，而是類似 CopyOnWriteArrayList 的命名，說明是讀寫單獨處理，來讓他成為執行緒安全的集合，那為什麼是 ArraySet 多一個 array 修飾語呢？

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

我們最擔心的可能 **產生問題的 remove 和 add 方法**，也是使用了 CopyOnWriteArrayList 的方法：而保證 set 的不重複性質的關鍵，顯然就**在於 CopyOnWriteArrayList 的 addIfAbsent 方法**，我們還是點進 CopyOnWriteArrayList 原始碼看一看這個方法的實現：

其中的 indexOfRange 方法：

可以看到，也是加了 Monitor 鎖來進行的，整個過程是這樣的： 1. 獲取本來的 set ，是一個數組，以**快照**形式返回當前的陣列； 2. indexOfRange 方法通過遍歷查詢查詢元素出現位置，addIfAbsent方法完成不存在則加入，如果前一個為 false 後一個就不會執行； 3. **加鎖**； 4. current 再次獲取一次當前的快照，因為有可能第一次判斷的過程有了其他執行緒的插入或者修改操作，此時已經不像等，就進入分支進行判斷是否存在； 5. 否則就要加入這個元素，和 CopyOnWriteArrayList 新增元素的最後操作是一樣的； 6. **解鎖**。總結一下就是，**執行緒安全的 Set 集合完全利用了 CopyOnWriteArrayList 集合的方法**，對應的操作也是**讀寫分別**處理，寫時複製的策略，**通過 jvm 層面的鎖來保證安全**，那麼保證不重複的方法就是遍歷進行比較。這樣看來，相比於基於 HashMap 的去重方法，效率肯定會降低，不過如果基於執行緒安全的 HashMap ，插入操作從hash、比較、到考慮**擴容**各方面會因為加鎖的過程更復雜，而對於一個不重複的 Set 來說，完全沒必要，所以應該綜合考慮之下采用了 List 為基礎，暴力迴圈去重。
# 三、HashMap 的執行緒不安全
關於 HashMap 的相關問題，原始碼裡已經分析過，大體是這樣的。不安全： 1. 普通讀寫不一致問題； 2. 死迴圈問題； 3. ConcurrentModificationException 異常。解決： 1. util包的Hashtable集合執行緒安全； 2. 用 synchronizedMap(new HashMap())包裝； 3. 使用 juc 包的 ConcurrentHashMap。 HashMap 和 ConcurrentHashMap 的原始碼分析： [HashMap原始碼解析、jdk7和8之後的區別、相關問題分析](https://www.cnblogs.com/lifegoeson/p/13628737.html) [ConcurrentHashMap原始碼解析，多執行緒擴容](https://www.cnblogs.com/lifegoeson/p/138034

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

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

Java集合整理（List and Set and Map）

Spring中集合（List，Set，Map）的配置和簡單使用（一）

【Java】集合系列18（Arrays和Collections工具類）

常用JAVA集合框架（Collection、List、Set、Map）

JAVA 集合類（Collection）、List、Set、Map、Collections與Arrays、泛型

【java讀書筆記】——Collection集合之六大介面（Collection、Set、List、Map、Iterator和Comparable）

【Java】集合（List、Set、Map）遍歷、刪除、比較元素時的小陷阱

Java集合：List、Set和Map的區別，ArrayList和LinkedList有何區別..........

java List 、Set 、Map集合聯絡與區別

【小家java】Java之Apache Commons-Collections4使用精講（含有Bag、Map、List、Set全覆蓋）

Java語言中List、Set、Map三種集合之間的區別

JAVA中幾種集合(List、Set和Map)的區別

Java集合Collection、List、Set、Map使用詳解

Java 之路 (十一) -- 持有物件（Collection、List、Set、Queue、Map、Iterator、foreach）

java基礎鞏固系列（九）：持有物件之間的使用與關係（Iterable、Collection、List、Queue、Set、Map、Stack）

Java基礎面試題3-說說你知道的幾個Java集合類：list、set、queue、map

Java集合類List、Set、Queue、Map實現類

Java集合中：List、Set、map的區別和具體的使用場景和高頻問題解析

Java常見集合框架(二):Iterable、Collection(List、Set、Queue)、AbstractCollection

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

相關推薦