我們已經(jīng)知道多線程下會有各種不安全的問題，都知道并發(fā)的基本解決方案，這里對出現(xiàn)錯誤的情況進行一個實際模擬，以此能夠聯(lián)想到具體的生產(chǎn)環(huán)境中。

一、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 的寫操作，并隨后進行輸出的讀操作。

輸出結果，多執(zhí)行幾次，驚喜多多。

那么，情況不嚴重的時候，這里顯然還正常運行結束了，只是導致了還沒來得及寫的時候，就已經(jīng)讀出了數(shù)據(jù)。

如果把線程數(shù)增加試試，可能還會看到這樣的奇觀：

報錯了：重點異常：java.util.ConcurrentModificationException，翻譯過來就是并發(fā)修改異常。

1.2 產(chǎn)生原因

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

那么在多線程同時操作的時候，按照操作的情況就有這幾種：

各個線程都讀。不影響，前提是只有讀；

各個線程都寫。會出現(xiàn)問題，這里的點有兩種情況：

值覆蓋問題，因為 ArrayList 的底層數(shù)組，寫入值的時候要先計算到一個下標位置，然后給對應的位置去賦值，多線程就會出現(xiàn)值覆蓋的問題； 空指針異常，因為 ArrayList 的底層數(shù)組，寫入值在數(shù)組滿的時候需要擴容，在擴容還沒完成的時候，新的下標卻已經(jīng)計算出來并且要去插入，那么就會出現(xiàn)空指針異常。

有的讀有的寫。那么顯然對于多個線程來說，2 里面各個線程寫的情況對應的問題就會出現(xiàn)。除此之外：

如果多線程有的讀有的寫，對于 ArrayList 底層，某些情況下，對象是不允許進行修改的，如果修改了，后面調用某些方法時，就會檢測到，然后就直接拋出ConcurrentModificationException。 具體一下，因為源碼里，寫操作對集合修改是寫，而next、remove等 Itr 的遍歷讀操作的時候會通過當前集合的修改次數(shù)與 Itr 對象創(chuàng)建時記錄的次數(shù)校驗集合是否被修改，如果修改了，不一致就說明正讀的時候還有別的線程在改，就會拋出異常。 JDK作者說了，會拋這個異常的都叫fail-fast iterator。

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

1.3 解決方法

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

同樣能夠完成 ArrayList 功能的，可以使用 Vector，查看源碼就會發(fā)現(xiàn)，Vector 的基本結構是一個叫 elementData 的 Object 類型的數(shù)組，和 ArrayList 類似，但是對應的操作方法，基本都加上了 synchronized 關鍵字，因此它是線程安全的集合。 數(shù)據(jù)量小的時候，使用 Collections.synchronizedList(new ArrayList())這種方式，來包裹這個集合，跟 Collections 里面 synchronizedMap包裹hashmap 是一樣的，更多的，還有：

顯然能傳入?yún)?shù)的這些基本集合類都是線程不安全的。

第三種就是，直接使用 juc 包里面的，CopyOnWriteArrayList() 類，這個類就是并發(fā)包給我們提供的線程安全的列表類。1.4里介紹了這個集合。

1.4 CopyOnWriteArrayList

對于 CopyOnWriteArrayList 類，名字上就可以聽的出來，寫時復制的列表。

首先，按照前面的我們的分析，只要涉及了寫的操作，和讀或者寫搭配的多線程情況，就會出現(xiàn)問題，那么多線程同時讀卻不會出現(xiàn)問題，因此相比較于直接都加上 synchronized 的方式，他的思想就是：讀寫分離。這個思想在數(shù)據(jù)庫對于高并發(fā)的架構層面也有一樣的設計。

這樣一來，對于這個 List 集合來說，分為不同操作的保證線程安全的策略，就能夠保證更好的性能。

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

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

加鎖 獲取到當前的集合數(shù)組； 計算長度； 調用 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 出現(xiàn)問題的原因

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

可以看到，源碼里面，Set 的底層維護的是一個 HashMap 來實現(xiàn)。對于遍歷操作來說，都是一樣的使用了 fail-fast iterator 迭代器，因此會出現(xiàn)這個異常。

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

put 的過程也是調用 map 的 put 方法。

2.3 解決方案

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

2.4 CopyOnWriteArraySet

按照前面的思路，List 的對應線程安全集合是在 List 集合的數(shù)組基礎上進行加鎖的相關操作。

那么 Set 既然底層是 HashMap，對應的線程安全集合就應該是對 HashMap 的線程安全集合進行加鎖，或者說直接用 ConcurrentHashMap 集合來實現(xiàn) CopyOnWriteArraySet 。

但事實上，源碼并不是這么做的。

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

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

然后每一個實現(xiàn)的方法都很簡單，基本是直接調用了 CopyOnWriteArrayList 的方法：

我們最擔心的可能 產(chǎn)生問題的 remove 和 add 方法，也是使用了 CopyOnWriteArrayList 的方法：

而保證 set 的不重復性質的關鍵，顯然就在于 CopyOnWriteArrayList 的 addIfAbsent 方法，我們還是點進 CopyOnWriteArrayList 源碼看一看這個方法的實現(xiàn)：

其中的 indexOfRange 方法：

可以看到，也是加了 Monitor 鎖來進行的，整個過程是這樣的：

獲取本來的 set ，是一個數(shù)組，以快照形式返回當前的數(shù)組； indexOfRange 方法通過遍歷查找查找元素出現(xiàn)位置，addIfAbsent方法完成不存在則加入，如果前一個為 false 后一個就不會執(zhí)行； 加鎖； current 再次獲取一次當前的快照，因為有可能第一次判斷的過程有了其他線程的插入或者修改操作，此時已經(jīng)不像等，就進入分支進行判斷是否存在； 否則就要加入這個元素，和 CopyOnWriteArrayList 添加元素的最后操作是一樣的； 解鎖。

總結一下就是，線程安全的 Set 集合完全利用了 CopyOnWriteArrayList 集合的方法，對應的操作也是讀寫分別處理，寫時復制的策略，通過 jvm 層面的鎖來保證安全，那么保證不重復的方法就是遍歷進行比較。

這樣看來，相比于基于 HashMap 的去重方法，效率肯定會降低，不過如果基于線程安全的 HashMap ，插入操作從hash、比較、到考慮擴容各方面會因為加鎖的過程更復雜，而對于一個不重復的 Set 來說，完全沒必要，所以應該綜合考慮之下采用了 List 為基礎，暴力循環(huán)去重。

三、HashMap 的線程不安全

關于 HashMap 的相關問題，源碼里已經(jīng)分析過，大體是這樣的。

不安全：

普通讀寫不一致問題； 死循環(huán)問題； ConcurrentModificationException 異常。

解決：

util包的Hashtable集合線程安全； 用 synchronizedMap(new HashMap())包裝； 使用 juc 包的 ConcurrentHashMap。

HashMap 和 ConcurrentHashMap 的源碼分析：

HashMap源碼解析、jdk7和8之后的區(qū)別、相關問題分析

ConcurrentHashMap源碼解析，多線程擴容

到此這篇關于java的各種集合為什么不安全(List、Set、Map)以及代替方案的文章就介紹到這了,更多相關java 集合不安全內容請搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持好吧啦網(wǎng)！