面試阿里被質問：ConcurrentHashMap 真的線程安全嗎?
點擊上方?藍字?關注我們！
Java，Python，C/C++，Linux，PHP，Go，C#，QT，大數(shù)據(jù)，算法，軟件教程，前端，簡歷，畢業(yè)設計等分類，資源在不斷更新中... 點擊領取！
沒啥深入實踐的理論系同學，在使用并發(fā)工具時，總是認為把HashMap改為ConcurrentHashMap，就完美解決并發(fā)了呀?；蛘呤褂脤憰r復制的CopyOnWriteArrayList，性能更佳呀！技術言論雖然自由，但面對魔鬼面試官時，我們更在乎的是這些真的正確嗎？
線程重用導致用戶信息錯亂
生產環(huán)境中，有時獲取到的用戶信息是別人的。查看代碼后，發(fā)現(xiàn)是使用了ThreadLocal緩存獲取到的用戶信息。
ThreadLocal適用于變量在線程間隔離，而在方法或類間共享的場景。若用戶信息的獲取比較昂貴（比如從DB查詢），則在ThreadLocal中緩存比較合適。問題來了，為什么有時會出現(xiàn)用戶信息錯亂？
案例
使用ThreadLocal存放一個Integer值，代表需要在線程中保存的用戶信息，初始null。先從ThreadLocal獲取一次值，然后把外部傳入的參數(shù)設置到ThreadLocal中，模擬從當前上下文獲取用戶信息，隨后再獲取一次值，最后輸出兩次獲得的值和線程名稱。
固定思維認為，在設置用戶信息前第一次獲取的值始終是null，但要清楚程序運行在Tomcat，執(zhí)行程序的線程是Tomcat的工作線程，其基于線程池。而線程池會重用固定線程，一旦線程重用，那么很可能首次從ThreadLocal獲取的值是之前其他用戶的請求遺留的值。這時，ThreadLocal中的用戶信息就是其他用戶的信息。
bug 重現(xiàn)
在配置文件設置Tomcat參數(shù)-工作線程池最大線程數(shù)設為1，這樣始終是同一線程在處理請求：
server.tomcat.max-threads=1
先讓用戶1請求接口，第一、第二次獲取到用戶ID分別是null和1，符合預期 用戶2請求接口，bug復現(xiàn)！第一、第二次獲取到用戶ID分別是1和2，顯然第一次獲取到了用戶1的信息，因為Tomcat線程池重用了線程。兩次請求線程都是同一線程：http-nio-45678-exec-1。
寫業(yè)務代碼時，首先要理解代碼會跑在什么線程上：
Tomcat服務器下跑的業(yè)務代碼，本就運行在一個多線程環(huán)境（否則接口也不可能支持這么高的并發(fā)），并不能認為沒有顯式開啟多線程就不會有線程安全問題 線程創(chuàng)建較昂貴，所以Web服務器會使用線程池處理請求，線程會被重用。使用類似ThreadLocal工具存放數(shù)據(jù)時，需注意在代碼運行完后，顯式清空設置的數(shù)據(jù)。
解決方案
在finally代碼塊顯式清除ThreadLocal中數(shù)據(jù)。即使新請求過來，使用了之前的線程，也不會獲取到錯誤的用戶信息。修正后代碼：
ThreadLocal利用獨占資源的解決線程安全問題，若就是要資源在線程間共享怎么辦？就需要用到線程安全的容器。使用了線程安全的并發(fā)工具，并不代表解決了所有線程安全問題。
ThreadLocalRandom 可將其實例設置到靜態(tài)變量，在多線程下重用嗎？
current()的時候初始化一個初始化種子到線程，每次nextseed再使用之前的種子生成新的種子：
UNSAFE.putLong(t?=?Thread.currentThread(),?SEED,
r?=?UNSAFE.getLong(t,?SEED)?+?GAMMA);
如果你通過主線程調用一次current生成一個ThreadLocalRandom實例保存，那么其它線程來獲取種子的時候必然取不到初始種子，必須是每一個線程自己用的時候初始化一個種子到線程?？梢栽趎extSeed設置一個斷點看看：
UNSAFE.getLong(Thread.currentThread(),SEED);
ConcurrentHashMap真的安全嗎？
我們都知道ConcurrentHashMap是個線程安全的哈希表容器，但它僅保證提供的原子性讀寫操作線程安全。
案例
有個含900個元素的Map，現(xiàn)在再補充100個元素進去，這個補充操作由10個線程并發(fā)進行。開發(fā)人員誤以為使用ConcurrentHashMap就不會有線程安全問題，于是不加思索地寫出了下面的代碼：在每一個線程的代碼邏輯中先通過size方法拿到當前元素數(shù)量，計算ConcurrentHashMap目前還需要補充多少元素，并在日志中輸出了這個值，然后通過putAll方法把缺少的元素添加進去。
為方便觀察問題，我們輸出了這個Map一開始和最后的元素個數(shù)。
訪問接口
分析日志輸出可得：
初始大小900符合預期，還需填充100個元素 worker13線程查詢到當前需要填充的元素為49，還不是100的倍數(shù) 最后HashMap的總項目數(shù)是1549，也不符合填充滿1000的預期
bug 分析
ConcurrentHashMap就像是一個大籃子，現(xiàn)在這個籃子里有900個桔子，我們期望把這個籃子裝滿1000個桔子，也就是再裝100個桔子。有10個工人來干這件事兒，大家先后到崗后會計算還需要補多少個桔子進去，最后把桔子裝入籃子。ConcurrentHashMap這籃子本身，可以確保多個工人在裝東西進去時，不會相互影響干擾，但無法確保工人A看到還需要裝100個桔子但是還未裝時，工人B就看不到籃子中的桔子數(shù)量。你往這個籃子裝100個桔子的操作不是原子性的，在別人看來可能會有一個瞬間籃子里有964個桔子，還需要補36個桔子。
ConcurrentHashMap對外提供能力的限制：
使用不代表對其的多個操作之間的狀態(tài)一致，是沒有其他線程在操作它的。如果需要確保需要手動加鎖 諸如size、isEmpty和containsValue等聚合方法，在并發(fā)下可能會反映ConcurrentHashMap的中間狀態(tài)。因此在并發(fā)情況下，這些方法的返回值只能用作參考，而不能用于流程控制。顯然，利用size方法計算差異值，是一個流程控制 諸如putAll這樣的聚合方法也不能確保原子性，在putAll的過程中去獲取數(shù)據(jù)可能會獲取到部分數(shù)據(jù)
解決方案
整段邏輯加鎖：
只有一個線程查詢到需補100個元素，其他9個線程查詢到無需補，最后Map大小1000
既然使用ConcurrentHashMap還要全程加鎖，還不如使用HashMap呢？不完全是這樣。
ConcurrentHashMap提供了一些原子性的簡單復合邏輯方法，用好這些方法就可以發(fā)揮其威力。這就引申出代碼中常見的另一個問題：在使用一些類庫提供的高級工具類時，開發(fā)人員可能還是按照舊的方式去使用這些新類，因為沒有使用其真實特性，所以無法發(fā)揮其威力。
知己知彼，百戰(zhàn)百勝
案例
使用Map來統(tǒng)計Key出現(xiàn)次數(shù)的場景。
使用ConcurrentHashMap來統(tǒng)計，Key的范圍是10 使用最多10個并發(fā)，循環(huán)操作1000萬次，每次操作累加隨機的Key 如果Key不存在的話，首次設置值為1。
show me code:
有了上節(jié)經驗，我們這直接鎖住Map，再做
判斷 讀取現(xiàn)在的累計值 +1 保存累加后值
這段代碼在功能上的確毫無沒有問題，但卻無法充分發(fā)揮ConcurrentHashMap的性能，優(yōu)化后：
ConcurrentHashMap的原子性方法computeIfAbsent做復合邏輯操作，判斷K是否存在V，若不存在，則把Lambda運行后結果存入Map作為V，即新創(chuàng)建一個LongAdder對象，最后返回V 因為computeIfAbsent返回的V是LongAdder，是個線程安全的累加器，可直接調用其increment累加。這樣在確保線程安全的情況下達到極致性能，且代碼行數(shù)驟減。
性能測試
使用StopWatch測試兩段代碼的性能，最后的斷言判斷Map中元素的個數(shù)及所有V的和是否符合預期來校驗代碼正確性 性能測試結果：比使用鎖性能提升至少5倍。
computeIfAbsent高性能之道
Java的Unsafe實現(xiàn)的CAS。它在JVM層確保寫入數(shù)據(jù)的原子性，比加鎖效率高：
static?final??boolean?casTabAt(Node[]?tab,?int?i,
????????????????????????????????????Node?c,?Node?v)?{
????return?U.compareAndSetObject(tab,?((long)i?<}
所以不要以為只要用了ConcurrentHashMap并發(fā)工具就是高性能的高并發(fā)程序。
辨明 computeIfAbsent、putIfAbsent
當Key存在的時候，如果Value獲取比較昂貴的話，putIfAbsent就白白浪費時間在獲取這個昂貴的Value上（這個點特別注意） Key不存在的時候，putIfAbsent返回null，小心空指針，而computeIfAbsent返回計算后的值 當Key不存在的時候，putIfAbsent允許put null進去，而computeIfAbsent不能，之后進行containsKey查詢是有區(qū)別的（當然了，此條針對HashMap，ConcurrentHashMap不允許put null value進去）
CopyOnWriteArrayList 之殤
再比如一段簡單的非 DB操作的業(yè)務邏輯，時間消耗卻超出預期時間，在修改數(shù)據(jù)時操作本地緩存比回寫DB慢許多。原來是有人使用了CopyOnWriteArrayList緩存大量數(shù)據(jù)，而該業(yè)務場景下數(shù)據(jù)變化又很頻繁。CopyOnWriteArrayList雖然是一個線程安全版的ArrayList，但其每次修改數(shù)據(jù)時都會復制一份數(shù)據(jù)出來，所以只適用讀多寫少或無鎖讀場景。所以一旦使用CopyOnWriteArrayList，一定是因為場景適宜而非炫技。
CopyOnWriteArrayList V.S 普通加鎖ArrayList讀寫性能
測試并發(fā)寫性能 測試結果：高并發(fā)寫，CopyOnWriteArray比同步ArrayList慢百倍 測試并發(fā)讀性能 測試結果：高并發(fā)讀（100萬次get操作），CopyOnWriteArray比同步ArrayList快24倍
高并發(fā)寫時，CopyOnWriteArrayList為何這么慢呢？因為其每次add時，都用Arrays.copyOf創(chuàng)建新數(shù)組，頻繁add時內存申請釋放性能消耗大。
總結
Don't !!!
不要只會用并發(fā)工具，而不熟悉線程原理 不要覺得用了并發(fā)工具，就怎么都線程安全 不熟悉并發(fā)工具的優(yōu)化本質，就難以發(fā)揮其真正性能 不要不結合當前業(yè)務場景，就隨意選用并發(fā)工具，可能導致系統(tǒng)性能更差
Do !!!
認真閱讀官方文檔，理解并發(fā)工具適用場景及其各API的用法，并自行測試驗證，最后再使用 并發(fā)bug本就不易復現(xiàn)， 多自行進行性能壓力測試
往期推薦
END
若覺得文章對你有幫助，隨手轉發(fā)分享，也是我們繼續(xù)更新的動力。
長按二維碼，掃掃關注哦
?「C語言中文網(wǎng)」官方公眾號，關注手機閱讀教程??
目前收集的資料包括：?Java，Python，C/C++，Linux，PHP，go，C#，QT，git/svn，人工智能，大數(shù)據(jù)，單片機，算法，小程序，易語言，安卓，ios，PPT，軟件教程，前端，軟件測試，簡歷，畢業(yè)設計，公開課?等分類，資源在不斷更新中...