沒啥深入實踐的理論系同學，在使用并發工具時，總是認為把HashMap改為ConcurrentHashMap，就完美解決并發了呀，或者使用寫時復制的CopyOnWriteArrayList，性能更佳呀！技術言論雖然自由，但面對魔鬼面試官時，我們更在乎的是這些真的正確嗎？2021Java面試寶典

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進去）