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

一、List 的不安全

1.1 問(wèn)題

看一段代碼：

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(); }}

過(guò)程很簡(jiǎn)單，只有 3 個(gè)線(xiàn)程而已，對(duì)同一個(gè) list 進(jìn)行 add 的寫(xiě)操作，并隨后進(jìn)行輸出的讀操作。

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

那么，情況不嚴(yán)重的時(shí)候，這里顯然還正常運(yùn)行結(jié)束了，只是導(dǎo)致了還沒(méi)來(lái)得及寫(xiě)的時(shí)候，就已經(jīng)讀出了數(shù)據(jù)。

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

報(bào)錯(cuò)了：重點(diǎn)異常：java.util.ConcurrentModificationException，翻譯過(guò)來(lái)就是并發(fā)修改異常。

1.2 產(chǎn)生原因

普通的 ArrayList 集合里面沒(méi)有任何特殊處理，在多線(xiàn)程情況下，他們可以共同進(jìn)行訪問(wèn)。

那么在多線(xiàn)程同時(shí)操作的時(shí)候，按照操作的情況就有這幾種：

各個(gè)線(xiàn)程都讀。不影響，前提是只有讀；

各個(gè)線(xiàn)程都寫(xiě)。會(huì)出現(xiàn)問(wèn)題，這里的點(diǎn)有兩種情況：

值覆蓋問(wèn)題，因?yàn)?ArrayList 的底層數(shù)組，寫(xiě)入值的時(shí)候要先計(jì)算到一個(gè)下標(biāo)位置，然后給對(duì)應(yīng)的位置去賦值，多線(xiàn)程就會(huì)出現(xiàn)值覆蓋的問(wèn)題； 空指針異常，因?yàn)?ArrayList 的底層數(shù)組，寫(xiě)入值在數(shù)組滿(mǎn)的時(shí)候需要擴(kuò)容，在擴(kuò)容還沒(méi)完成的時(shí)候，新的下標(biāo)卻已經(jīng)計(jì)算出來(lái)并且要去插入，那么就會(huì)出現(xiàn)空指針異常。

有的讀有的寫(xiě)。那么顯然對(duì)于多個(gè)線(xiàn)程來(lái)說(shuō)，2 里面各個(gè)線(xiàn)程寫(xiě)的情況對(duì)應(yīng)的問(wèn)題就會(huì)出現(xiàn)。除此之外：

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

第 3 種情況就是對(duì)應(yīng)了我們上面的代碼在線(xiàn)程多起來(lái)的情況，因?yàn)檩敵?list 的時(shí)候需要遍歷的讀，而此時(shí)還有別的線(xiàn)程在進(jìn)行 add 的修改操作。

1.3 解決方法

注意：當(dāng)然不能自己加鎖，因?yàn)榧项?lèi)已經(jīng)再演變過(guò)程有線(xiàn)程安全的替代品，自己的代碼加鎖的粒度已經(jīng)在集合的外層再加一層了，粒度太大。

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

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

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

1.4 CopyOnWriteArrayList

對(duì)于 CopyOnWriteArrayList 類(lèi)，名字上就可以聽(tīng)的出來(lái)，寫(xiě)時(shí)復(fù)制的列表。

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

這樣一來(lái)，對(duì)于這個(gè) List 集合來(lái)說(shuō)，分為不同操作的保證線(xiàn)程安全的策略，就能夠保證更好的性能。

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

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

加鎖 獲取到當(dāng)前的集合數(shù)組； 計(jì)算長(zhǎng)度； 調(diào)用 Arrays.copyOf 方法進(jìn)行添加操作，每次只添加一個(gè)元素進(jìn)去； 修改引用，更新最新的集合； return true。 解鎖

其中的 lock 在源碼里就是一個(gè)：

可以看到是一個(gè)普通的 Object。

那么加鎖的時(shí)候就用 synchronized 對(duì) Object 進(jìn)行加鎖，沒(méi)有采用 juc 的 ReetrantLock，注釋li也寫(xiě)了，偏向于使用內(nèi)置的 monitor 也就是 synchronized 底層 monitor 鎖，這一點(diǎn)也充分說(shuō)明了 synchronized 的性能更新使得源碼作者使用它。

這個(gè)方法是處理最直接的，其他對(duì)應(yīng)的寫(xiě)操作：remove、set等等也是一樣的基礎(chǔ)流程。

我們?cè)賮?lái)看看讀操作 get 方法：

二、HashSet 的不安全

2.1 問(wèn)題及原因

我們還是用 List 一樣的測(cè)試代碼；

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(); } }}

就會(huì)看到一樣的錯(cuò)誤：

2.2 出現(xiàn)問(wèn)題的原因

其實(shí)從出現(xiàn) ConcurrentModificationException 異常來(lái)看，我們可以猜測(cè)是和 List 類(lèi)似的原因?qū)е碌漠惓！?/p>

可以看到，源碼里面，Set 的底層維護(hù)的是一個(gè) HashMap 來(lái)實(shí)現(xiàn)。對(duì)于遍歷操作來(lái)說(shuō)，都是一樣的使用了 fail-fast iterator 迭代器，因此會(huì)出現(xiàn)這個(gè)異常。

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

put 的過(guò)程也是調(diào)用 map 的 put 方法。

2.3 解決方案

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

2.4 CopyOnWriteArraySet

按照前面的思路，List 的對(duì)應(yīng)線(xiàn)程安全集合是在 List 集合的數(shù)組基礎(chǔ)上進(jìn)行加鎖的相關(guān)操作。

那么 Set 既然底層是 HashMap，對(duì)應(yīng)的線(xiàn)程安全集合就應(yīng)該是對(duì) HashMap 的線(xiàn)程安全集合進(jìn)行加鎖，或者說(shuō)直接用 ConcurrentHashMap 集合來(lái)實(shí)現(xiàn) CopyOnWriteArraySet 。

但事實(shí)上，源碼并不是這么做的。

從名字來(lái)看，和 ConcurrentHashMap 也沒(méi)有什么關(guān)系，而是類(lèi)似 CopyOnWriteArrayList 的命名，說(shuō)明是讀寫(xiě)單獨(dú)處理，來(lái)讓他成為線(xiàn)程安全的集合，那為什么是 ArraySet 多一個(gè) array 修飾語(yǔ)呢？

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

然后每一個(gè)實(shí)現(xiàn)的方法都很簡(jiǎn)單，基本是直接調(diào)用了 CopyOnWriteArrayList 的方法：

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

而保證 set 的不重復(fù)性質(zhì)的關(guān)鍵，顯然就在于 CopyOnWriteArrayList 的 addIfAbsent 方法，我們還是點(diǎn)進(jìn) CopyOnWriteArrayList 源碼看一看這個(gè)方法的實(shí)現(xiàn)：

其中的 indexOfRange 方法：

可以看到，也是加了 Monitor 鎖來(lái)進(jìn)行的，整個(gè)過(guò)程是這樣的：

獲取本來(lái)的 set ，是一個(gè)數(shù)組，以快照形式返回當(dāng)前的數(shù)組； indexOfRange 方法通過(guò)遍歷查找查找元素出現(xiàn)位置，addIfAbsent方法完成不存在則加入，如果前一個(gè)為 false 后一個(gè)就不會(huì)執(zhí)行； 加鎖； current 再次獲取一次當(dāng)前的快照，因?yàn)橛锌赡艿谝淮闻袛嗟倪^(guò)程有了其他線(xiàn)程的插入或者修改操作，此時(shí)已經(jīng)不像等，就進(jìn)入分支進(jìn)行判斷是否存在； 否則就要加入這個(gè)元素，和 CopyOnWriteArrayList 添加元素的最后操作是一樣的； 解鎖。

總結(jié)一下就是，線(xiàn)程安全的 Set 集合完全利用了 CopyOnWriteArrayList 集合的方法，對(duì)應(yīng)的操作也是讀寫(xiě)分別處理，寫(xiě)時(shí)復(fù)制的策略，通過(guò) jvm 層面的鎖來(lái)保證安全，那么保證不重復(fù)的方法就是遍歷進(jìn)行比較。

這樣看來(lái)，相比于基于 HashMap 的去重方法，效率肯定會(huì)降低，不過(guò)如果基于線(xiàn)程安全的 HashMap ，插入操作從hash、比較、到考慮擴(kuò)容各方面會(huì)因?yàn)榧渔i的過(guò)程更復(fù)雜，而對(duì)于一個(gè)不重復(fù)的 Set 來(lái)說(shuō)，完全沒(méi)必要，所以應(yīng)該綜合考慮之下采用了 List 為基礎(chǔ)，暴力循環(huán)去重。

三、HashMap 的線(xiàn)程不安全

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

不安全：

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

解決：

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

HashMap 和 ConcurrentHashMap 的源碼分析：

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

ConcurrentHashMap源碼解析，多線(xiàn)程擴(kuò)容

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