我們已經(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)問題，這里的點有兩種情況：

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

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

1. 如果多線程有的讀有的寫，對于 ArrayList 底層，某些情況下，對象是不允許進行修改的，如果修改了，后面調(diào)用某些方法時，就會檢測到，然后就直接拋出ConcurrentModificationException。
2. 具體一下，因為源碼里，寫操作對集合修改是寫，而next、remove等 Itr 的遍歷讀操作的時候會通過當前集合的修改次數(shù)與 Itr 對象創(chuàng)建時記錄的次數(shù)校驗集合是否被修改，如果修改了，不一致就說明正讀的時候還有別的線程在改，就會拋出異常。
3. 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ù)組；
• 計算長度；
• 調(diào)用 Arrays.copyOf 方法進行添加操作，每次只添加一個元素進去；
• 修改引用，更新最新的集合；
• return true。
• 解鎖

其中的 lock 在源碼里就是一個：

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

那么加鎖的時候就用 synchronized 對 Object 進行加鎖，沒有采用 juc 的 ReetrantLock，注釋li也寫了，偏向于使用內(nèi)置的 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 類似的原因?qū)е碌漠惓！?/p>

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

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

put 的過程也是調(diào)用 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)的方法都很簡單，基本是直接調(diào)用了 CopyOnWriteArrayList 的方法：

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

而保證 set 的不重復性質(zhì)的關鍵，顯然就在于 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 集合不安全內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！