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

時間 2021-01-31

標籤面試數組緩存 tomcat 安全服務器多線程併發 dom ide 欄目快樂工作简体版

原文原文鏈接

沒啥深刻實踐的理論系同窗，在使用併發工具時，老是認爲把HashMap改成ConcurrentHashMap，就完美解決併發了呀。或者使用寫時複製的CopyOnWriteArrayList，性能更佳呀！技術言論雖然自由，但面對魔鬼面試官時，咱們更在意的是這些真的正確嗎？2021Java面試寶典面試

1 線程重用致使用戶信息錯亂

生產環境中，有時獲取到的用戶信息是別人的。查看代碼後，發現是使用了ThreadLocal緩存獲取到的用戶信息。數組

ThreadLocal適用於變量在線程間隔離，而在方法或類間共享的場景。
若用戶信息的獲取比較昂貴（好比從DB查詢），則在ThreadLocal中緩存比較合適。
問題來了，爲何有時會出現用戶信息錯亂？緩存

1.1 案例

使用ThreadLocal存放一個Integer值，表明須要在線程中保存的用戶信息，初始null。
先從ThreadLocal獲取一次值，而後把外部傳入的參數設置到ThreadLocal中，模擬從當前上下文獲取用戶信息，隨後再獲取一次值，最後輸出兩次得到的值和線程名稱。
tomcat

固定思惟認爲，在設置用戶信息前第一次獲取的值始終是null，但要清楚程序運行在Tomcat，執行程序的線程是Tomcat的工做線程，其基於線程池。
而線程池會重用固定線程，一旦線程重用，那麼極可能首次從ThreadLocal獲取的值是以前其餘用戶的請求遺留的值。這時，ThreadLocal中的用戶信息就是其餘用戶的信息。安全

1.2 bug 重現

在配置文件設置Tomcat參數-工做線程池最大線程數設爲1，這樣始終是同一線程在處理請求：服務器

server.tomcat.max-threads=1

先讓用戶1請求接口，第1、第二次獲取到用戶ID分別是null和1，符合預期
多線程

用戶2請求接口，bug復現！第1、第二次獲取到用戶ID分別是1和2，顯然第一次獲取到了用戶1的信息，由於Tomcat線程池重用了線程。兩次請求線程都是同一線程：http-nio-45678-exec-1。
併發

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

Tomcat服務器下跑的業務代碼，本就運行在一個多線程環境（不然接口也不可能支持這麼高的併發），並不能認爲沒有顯式開啓多線程就不會有線程安全問題ide
線程建立較昂貴，因此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進去）