面試阿裡被質問：ConcurrentHashMap線程安全嗎

沒啥深入實踐的理論系同學，在使用并發工具時，總是認為把

HashMap

改為

ConcurrentHashMap

，就完美解決并發了呀。或者使用寫時複制的

CopyOnWriteArrayList

，性能更佳呀！技術言論雖然自由，但面對魔鬼面試官時，我們更在乎的是這些真的正确嗎？

1 線程重用導緻使用者資訊錯亂

生産環境中，有時擷取到的使用者資訊是别人的。檢視代碼後，發現是使用了

ThreadLocal

緩存擷取到的使用者資訊。

ThreadLocal

适用于變量線上程間隔離，而在方法或類間共享的場景。

若使用者資訊的擷取比較昂貴（比如從DB查詢），則在

ThreadLocal

中緩存比較合适。

問題來了，為什麼有時會出現使用者資訊錯亂？

1.1 案例

使用ThreadLocal存放一個Integer值，代表需要線上程中儲存的使用者資訊，初始null。

先從ThreadLocal擷取一次值，然後把外部傳入的參數設定到ThreadLocal中，模拟從目前上下文擷取使用者資訊，随後再擷取一次值，最後輸出兩次獲得的值和線程名稱。

固定思維認為，在設定使用者資訊前第一次擷取的值始終是null，但要清楚程式運作在Tomcat，執行程式的線程是Tomcat的工作線程，其基于線程池。

而線程池會重用固定線程，一旦線程重用，那麼很可能首次從ThreadLocal擷取的值是之前其他使用者的請求遺留的值。這時，ThreadLocal中的使用者資訊就是其他使用者的資訊。

1.2 bug 重制

在配置檔案設定Tomcat參數-工作線程池最大線程數設為1，這樣始終是同一線程在處理請求：

server.tomcat.max-threads=1           

• 先讓使用者1請求接口，第一、第二次擷取到使用者ID分别是null和1，符合預期

  

• 使用者2請求接口，bug複現！第一、第二次擷取到使用者ID分别是1和2，顯然第一次擷取到了使用者1的資訊，因為Tomcat線程池重用了線程。兩次請求線程都是同一線程：

  http-nio-45678-exec-1

  。

  

寫業務代碼時，首先要了解代碼會跑在什麼線程上：

• Tomcat伺服器下跑的業務代碼，本就運作在一個多線程環境（否則接口也不可能支援這麼高的并發），并不能認為沒有顯式開啟多線程就不會有線程安全問題
• 線程建立較昂貴，是以Web伺服器會使用線程池處理請求，線程會被重用。使用類似ThreadLocal工具存放資料時，需注意在代碼運作完後，顯式清空設定的資料。

1.3 解決方案

在finally代碼塊顯式清除ThreadLocal中資料。即使新請求過來，使用了之前的線程，也不會擷取到錯誤的使用者資訊。

修正後代碼：

ThreadLocal利用獨占資源的解決線程安全問題，若就是要資源線上程間共享怎麼辦？就需要用到線程安全的容器。

使用了線程安全的并發工具，并不代表解決了所有線程安全問題。

1.4 ThreadLocalRandom 可将其執行個體設定到靜态變量，在多線程下重用嗎？

current()的時候初始化一個初始化種子到線程，每次nextseed再使用之前的種子生成新的種子：

UNSAFE.putLong(t = Thread.currentThread(), SEED,
r = UNSAFE.getLong(t, SEED) + GAMMA);           

如果你通過主線程調用一次current生成一個ThreadLocalRandom執行個體儲存，那麼其它線程來擷取種子的時候必然取不到初始種子，必須是每一個線程自己用的時候初始化一個種子到線程。

可以在nextSeed設定一個斷點看看：

UNSAFE.getLong(Thread.currentThread(),SEED);           

2 ConcurrentHashMap真的安全嗎？

我們都知道ConcurrentHashMap是個線程安全的哈希表容器，但它僅保證提供的原子性讀寫操作線程安全。

2.1 案例

有個含900個元素的Map，現在再補充100個元素進去，這個補充操作由10個線程并發進行。

開發人員誤以為使用ConcurrentHashMap就不會有線程安全問題，于是不加思索地寫出了下面的代碼：在每一個線程的代碼邏輯中先通過size方法拿到目前元素數量，計算ConcurrentHashMap目前還需要補充多少元素，并在日志中輸出了這個值，然後通過putAll方法把缺少的元素添加進去。

為友善觀察問題，我們輸出了這個Map一開始和最後的元素個數。

• 通路接口

  

分析日志輸出可得：

• 初始大小900符合預期，還需填充100個元素
• worker13線程查詢到目前需要填充的元素為49，還不是100的倍數
• 最後HashMap的總項目數是1549，也不符合填充滿1000的預期

2.2 bug 分析

ConcurrentHashMap就像是一個大籃子，現在這個籃子裡有900個桔子，我們期望把這個籃子裝滿1000個桔子，也就是再裝100個桔子。有10個勞工來幹這件事兒，大家先後到崗後會計算還需要補多少個桔子進去，最後把桔子裝入籃子。

ConcurrentHashMap這籃子本身，可以確定多個勞工在裝東西進去時，不會互相影響幹擾，但無法確定勞工A看到還需要裝100個桔子但是還未裝時，勞工B就看不到籃子中的桔子數量。你往這個籃子裝100個桔子的操作不是原子性的，在别人看來可能會有一個瞬間籃子裡有964個桔子，還需要補36個桔子。

ConcurrentHashMap對外提供能力的限制：

• 使用不代表對其的多個操作之間的狀态一緻，是沒有其他線程在操作它的。如果需要確定需要手動加鎖
• 諸如size、isEmpty和containsValue等聚合方法，在并發下可能會反映ConcurrentHashMap的中間狀态。是以在并發情況下，這些方法的傳回值隻能用作參考，而不能用于流程控制。顯然，利用size方法計算差異值，是一個流程控制
• 諸如putAll這樣的聚合方法也不能確定原子性，在putAll的過程中去擷取資料可能會擷取到部分資料

2.3 解決方案

整段邏輯加鎖：

• 隻有一個線程查詢到需補100個元素，其他9個線程查詢到無需補，最後Map大小1000

  

既然使用ConcurrentHashMap還要全程加鎖，還不如使用HashMap呢？

不完全是這樣。

ConcurrentHashMap提供了一些原子性的簡單複合邏輯方法，用好這些方法就可以發揮其威力。這就引申出代碼中常見的另一個問題：在使用一些類庫提供的進階工具類時，開發人員可能還是按照舊的方式去使用這些新類，因為沒有使用其真實特性，是以無法發揮其威力。

3 知己知彼，百戰百勝

3.1 案例

使用Map來統計Key出現次數的場景。

• 使用ConcurrentHashMap來統計，Key的範圍是10
• 使用最多10個并發，循環操作1000萬次，每次操作累加随機的Key
• 如果Key不存在的話，首次設定值為1。

show me code:

有了上節經驗，我們這直接鎖住Map，再做

• 判斷
• 讀取現在的累計值
• +1
• 儲存累加後值

這段代碼在功能上的确毫無沒有問題，但卻無法充分發揮ConcurrentHashMap的性能，優化後：

• ConcurrentHashMap

  的原子性方法

  computeIfAbsent

  做複合邏輯操作，判斷K是否存在V，若不存在，則把Lambda運作後結果存入Map作為V，即新建立一個

  LongAdder

  對象，最後傳回V

  因為

  computeIfAbsent

  傳回的V是

  LongAdder

  ，是個線程安全的累加器，可直接調用其

  increment

  累加。

這樣在確定線程安全的情況下達到極緻性能，且代碼行數驟減。

3.2 性能測試

• 使用StopWatch測試兩段代碼的性能，最後的斷言判斷Map中元素的個數及所有V的和是否符合預期來校驗代碼正确性

  

• 性能測試結果：

  

比使用鎖性能提升至少5倍。

3.3 computeIfAbsent高性能之道

Java的Unsafe實作的CAS。

它在JVM層確定寫入資料的原子性，比加鎖效率高：

static final <K,V> boolean casTabAt(Node<K,V>[] tab, int i,
                                    Node<K,V> c, Node<K,V> v) {
    return U.compareAndSetObject(tab, ((long)i << ASHIFT) + ABASE, c, v);
}           

是以不要以為隻要用了ConcurrentHashMap并發工具就是高性能的高并發程式。

辨明 computeIfAbsent、putIfAbsent

• 當Key存在的時候，如果Value擷取比較昂貴的話，putIfAbsent就白白浪費時間在擷取這個昂貴的Value上（這個點特别注意）
• Key不存在的時候，putIfAbsent傳回null，小心空指針，而computeIfAbsent傳回計算後的值
• 當Key不存在的時候，putIfAbsent允許put null進去，而computeIfAbsent不能，之後進行containsKey查詢是有差別的（當然了，此條針對HashMap，ConcurrentHashMap不允許put null value進去）

3.4 CopyOnWriteArrayList 之殇

再比如一段簡單的非 DB操作的業務邏輯，時間消耗卻超出預期時間，在修改資料時操作本地緩存比回寫DB慢許多。原來是有人使用了

CopyOnWriteArrayList

緩存大量資料，而該業務場景下資料變化又很頻繁。

CopyOnWriteArrayList

雖然是一個線程安全版的ArrayList，但其每次修改資料時都會複制一份資料出來，是以隻适用讀多寫少或無鎖讀場景。

是以一旦使用

CopyOnWriteArrayList

，一定是因為場景适宜而非炫技。

CopyOnWriteArrayList V.S 普通加鎖ArrayList讀寫性能

• 測試并發寫性能

  

• 測試結果：高并發寫，CopyOnWriteArray比同步ArrayList慢百倍

  

• 測試并發讀性能

  

• 測試結果：高并發讀（100萬次get操作），CopyOnWriteArray比同步ArrayList快24倍

  

高并發寫時，CopyOnWriteArrayList為何這麼慢呢？因為其每次add時，都用Arrays.copyOf建立新數組，頻繁add時記憶體申請釋放性能消耗大。

4 總結

4.1 Don't !!!

• 不要隻會用并發工具，而不熟悉線程原理
• 不要覺得用了并發工具，就怎麼都線程安全
• 不熟悉并發工具的優化本質，就難以發揮其真正性能
• 不要不結合目前業務場景，就随意選用并發工具，可能導緻系統性能更差

4.2 Do !!!

• 認真閱讀官方文檔，了解并發工具适用場景及其各API的用法，并自行測試驗證，最後再使用
• 并發bug本就不易複現， 多自行進行性能壓力測試

參考

• https://zhuanlan.zhihu.com/p/201333611