面試阿里被質(zhì)問(wèn)：ConcurrentHashMap線程安全嗎

沒(méi)啥深入實(shí)踐的理論系同學(xué)，在使用并發(fā)工具時(shí)，總是認(rèn)為把HashMap改為ConcurrentHashMap，就完美解決并發(fā)了呀?；蛘呤褂脤憰r(shí)復(fù)制的CopyOnWriteArrayList，性能更佳呀！技術(shù)言論雖然自由，但面對(duì)魔鬼面試官時(shí)，我們更在乎的是這些真的正確嗎？

線程重用導(dǎo)致用戶信息錯(cuò)亂

生產(chǎn)環(huán)境中，有時(shí)獲取到的用戶信息是別人的。查看代碼后，發(fā)現(xiàn)是使用了ThreadLocal緩存獲取到的用戶信息。

ThreadLocal適用于變量在線程間隔離，而在方法或類間共享的場(chǎng)景。若用戶信息的獲取比較昂貴（比如從DB查詢），則在ThreadLocal中緩存比較合適。問(wèn)題來(lái)了，為什么有時(shí)會(huì)出現(xiàn)用戶信息錯(cuò)亂？

案例

使用ThreadLocal存放一個(gè)Integer值，代表需要在線程中保存的用戶信息，初始null。先從ThreadLocal獲取一次值，然后把外部傳入的參數(shù)設(shè)置到ThreadLocal中，模擬從當(dāng)前上下文獲取用戶信息，隨后再獲取一次值，最后輸出兩次獲得的值和線程名稱。

固定思維認(rèn)為，在設(shè)置用戶信息前第一次獲取的值始終是null，但要清楚程序運(yùn)行在Tomcat，執(zhí)行程序的線程是Tomcat的工作線程，其基于線程池。而線程池會(huì)重用固定線程，一旦線程重用，那么很可能首次從ThreadLocal獲取的值是之前其他用戶的請(qǐng)求遺留的值。這時(shí)，ThreadLocal中的用戶信息就是其他用戶的信息。

bug 重現(xiàn)

在配置文件設(shè)置Tomcat參數(shù)-工作線程池最大線程數(shù)設(shè)為1，這樣始終是同一線程在處理請(qǐng)求：

server.tomcat.max-threads=1

• 先讓用戶1請(qǐng)求接口，第一、第二次獲取到用戶ID分別是null和1，符合預(yù)期
• 用戶2請(qǐng)求接口，bug復(fù)現(xiàn)！第一、第二次獲取到用戶ID分別是1和2，顯然第一次獲取到了用戶1的信息，因?yàn)門omcat線程池重用了線程。兩次請(qǐng)求線程都是同一線程：http-nio-45678-exec-1。

寫業(yè)務(wù)代碼時(shí)，首先要理解代碼會(huì)跑在什么線程上：

• Tomcat服務(wù)器下跑的業(yè)務(wù)代碼，本就運(yùn)行在一個(gè)多線程環(huán)境（否則接口也不可能支持這么高的并發(fā)），并不能認(rèn)為沒(méi)有顯式開啟多線程就不會(huì)有線程安全問(wèn)題
• 線程創(chuàng)建較昂貴，所以Web服務(wù)器會(huì)使用線程池處理請(qǐng)求，線程會(huì)被重用。使用類似ThreadLocal工具存放數(shù)據(jù)時(shí)，需注意在代碼運(yùn)行完后，顯式清空設(shè)置的數(shù)據(jù)。

解決方案

在finally代碼塊顯式清除ThreadLocal中數(shù)據(jù)。即使新請(qǐng)求過(guò)來(lái)，使用了之前的線程，也不會(huì)獲取到錯(cuò)誤的用戶信息。修正后代碼：

ThreadLocal利用獨(dú)占資源的解決線程安全問(wèn)題，若就是要資源在線程間共享怎么辦？就需要用到線程安全的容器。使用了線程安全的并發(fā)工具，并不代表解決了所有線程安全問(wèn)題。

ThreadLocalRandom 可將其實(shí)例設(shè)置到靜態(tài)變量，在多線程下重用嗎？

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

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

如果你通過(guò)主線程調(diào)用一次current生成一個(gè)ThreadLocalRandom實(shí)例保存，那么其它線程來(lái)獲取種子的時(shí)候必然取不到初始種子，必須是每一個(gè)線程自己用的時(shí)候初始化一個(gè)種子到線程?？梢栽趎extSeed設(shè)置一個(gè)斷點(diǎn)看看：

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

ConcurrentHashMap真的安全嗎？

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

案例

有個(gè)含900個(gè)元素的Map，現(xiàn)在再補(bǔ)充100個(gè)元素進(jìn)去，這個(gè)補(bǔ)充操作由10個(gè)線程并發(fā)進(jìn)行。開發(fā)人員誤以為使用ConcurrentHashMap就不會(huì)有線程安全問(wèn)題，于是不加思索地寫出了下面的代碼：在每一個(gè)線程的代碼邏輯中先通過(guò)size方法拿到當(dāng)前元素?cái)?shù)量，計(jì)算ConcurrentHashMap目前還需要補(bǔ)充多少元素，并在日志中輸出了這個(gè)值，然后通過(guò)putAll方法把缺少的元素添加進(jìn)去。

為方便觀察問(wèn)題，我們輸出了這個(gè)Map一開始和最后的元素個(gè)數(shù)。

• 訪問(wèn)接口

分析日志輸出可得：

• 初始大小900符合預(yù)期，還需填充100個(gè)元素
• worker13線程查詢到當(dāng)前需要填充的元素為49，還不是100的倍數(shù)
• 最后HashMap的總項(xiàng)目數(shù)是1549，也不符合填充滿1000的預(yù)期

bug 分析

ConcurrentHashMap就像是一個(gè)大籃子，現(xiàn)在這個(gè)籃子里有900個(gè)桔子，我們期望把這個(gè)籃子裝滿1000個(gè)桔子，也就是再裝100個(gè)桔子。有10個(gè)工人來(lái)干這件事兒，大家先后到崗后會(huì)計(jì)算還需要補(bǔ)多少個(gè)桔子進(jìn)去，最后把桔子裝入籃子。ConcurrentHashMap這籃子本身，可以確保多個(gè)工人在裝東西進(jìn)去時(shí)，不會(huì)相互影響干擾，但無(wú)法確保工人A看到還需要裝100個(gè)桔子但是還未裝時(shí)，工人B就看不到籃子中的桔子數(shù)量。你往這個(gè)籃子裝100個(gè)桔子的操作不是原子性的，在別人看來(lái)可能會(huì)有一個(gè)瞬間籃子里有964個(gè)桔子，還需要補(bǔ)36個(gè)桔子。

ConcurrentHashMap對(duì)外提供能力的限制：

• 使用不代表對(duì)其的多個(gè)操作之間的狀態(tài)一致，是沒(méi)有其他線程在操作它的。如果需要確保需要手動(dòng)加鎖
• 諸如size、isEmpty和containsValue等聚合方法，在并發(fā)下可能會(huì)反映ConcurrentHashMap的中間狀態(tài)。因此在并發(fā)情況下，這些方法的返回值只能用作參考，而不能用于流程控制。顯然，利用size方法計(jì)算差異值，是一個(gè)流程控制
• 諸如putAll這樣的聚合方法也不能確保原子性，在putAll的過(guò)程中去獲取數(shù)據(jù)可能會(huì)獲取到部分?jǐn)?shù)據(jù)

解決方案

整段邏輯加鎖：

• 只有一個(gè)線程查詢到需補(bǔ)100個(gè)元素，其他9個(gè)線程查詢到無(wú)需補(bǔ)，最后Map大小1000

既然使用ConcurrentHashMap還要全程加鎖，還不如使用HashMap呢？不完全是這樣。

ConcurrentHashMap提供了一些原子性的簡(jiǎn)單復(fù)合邏輯方法，用好這些方法就可以發(fā)揮其威力。這就引申出代碼中常見(jiàn)的另一個(gè)問(wèn)題：在使用一些類庫(kù)提供的高級(jí)工具類時(shí)，開發(fā)人員可能還是按照舊的方式去使用這些新類，因?yàn)闆](méi)有使用其真實(shí)特性，所以無(wú)法發(fā)揮其威力。

知己知彼，百戰(zhàn)百勝

案例

使用Map來(lái)統(tǒng)計(jì)Key出現(xiàn)次數(shù)的場(chǎng)景。

• 使用ConcurrentHashMap來(lái)統(tǒng)計(jì)，Key的范圍是10
• 使用最多10個(gè)并發(fā)，循環(huán)操作1000萬(wàn)次，每次操作累加隨機(jī)的Key
• 如果Key不存在的話，首次設(shè)置值為1。

show me code:

有了上節(jié)經(jīng)驗(yàn)，我們這直接鎖住Map，再做

• 判斷
• 讀取現(xiàn)在的累計(jì)值
• +1
• 保存累加后值

這段代碼在功能上的確毫無(wú)沒(méi)有問(wèn)題，但卻無(wú)法充分發(fā)揮ConcurrentHashMap的性能，優(yōu)化后：

• ConcurrentHashMap的原子性方法computeIfAbsent做復(fù)合邏輯操作，判斷K是否存在V，若不存在，則把Lambda運(yùn)行后結(jié)果存入Map作為V，即新創(chuàng)建一個(gè)LongAdder對(duì)象，最后返回V 因?yàn)閏omputeIfAbsent返回的V是LongAdder，是個(gè)線程安全的累加器，可直接調(diào)用其increment累加。這樣在確保線程安全的情況下達(dá)到極致性能，且代碼行數(shù)驟減。

性能測(cè)試

• 使用StopWatch測(cè)試兩段代碼的性能，最后的斷言判斷Map中元素的個(gè)數(shù)及所有V的和是否符合預(yù)期來(lái)校驗(yàn)代碼正確性
• 性能測(cè)試結(jié)果：比使用鎖性能提升至少5倍。

computeIfAbsent高性能之道

Java的Unsafe實(shí)現(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

• 當(dāng)Key存在的時(shí)候，如果Value獲取比較昂貴的話，putIfAbsent就白白浪費(fèi)時(shí)間在獲取這個(gè)昂貴的Value上（這個(gè)點(diǎn)特別注意）
• Key不存在的時(shí)候，putIfAbsent返回null，小心空指針，而computeIfAbsent返回計(jì)算后的值
• 當(dāng)Key不存在的時(shí)候，putIfAbsent允許put null進(jìn)去，而computeIfAbsent不能，之后進(jìn)行containsKey查詢是有區(qū)別的（當(dāng)然了，此條針對(duì)HashMap，ConcurrentHashMap不允許put null value進(jìn)去）

CopyOnWriteArrayList 之殤

再比如一段簡(jiǎn)單的非 DB操作的業(yè)務(wù)邏輯，時(shí)間消耗卻超出預(yù)期時(shí)間，在修改數(shù)據(jù)時(shí)操作本地緩存比回寫DB慢許多。原來(lái)是有人使用了CopyOnWriteArrayList緩存大量數(shù)據(jù)，而該業(yè)務(wù)場(chǎng)景下數(shù)據(jù)變化又很頻繁。CopyOnWriteArrayList雖然是一個(gè)線程安全版的ArrayList，但其每次修改數(shù)據(jù)時(shí)都會(huì)復(fù)制一份數(shù)據(jù)出來(lái)，所以只適用讀多寫少或無(wú)鎖讀場(chǎng)景。所以一旦使用CopyOnWriteArrayList，一定是因?yàn)閳?chǎng)景適宜而非炫技。

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

• 測(cè)試并發(fā)寫性能
• 測(cè)試結(jié)果：高并發(fā)寫，CopyOnWriteArray比同步ArrayList慢百倍
• 測(cè)試并發(fā)讀性能
• 測(cè)試結(jié)果：高并發(fā)讀（100萬(wàn)次get操作），CopyOnWriteArray比同步ArrayList快24倍

高并發(fā)寫時(shí)，CopyOnWriteArrayList為何這么慢呢？因?yàn)槠涿看蝍dd時(shí)，都用Arrays.copyOf創(chuàng)建新數(shù)組，頻繁add時(shí)內(nèi)存申請(qǐng)釋放性能消耗大。

總結(jié)

Don't !!!

• 不要只會(huì)用并發(fā)工具，而不熟悉線程原理
• 不要覺(jué)得用了并發(fā)工具，就怎么都線程安全
• 不熟悉并發(fā)工具的優(yōu)化本質(zhì)，就難以發(fā)揮其真正性能
• 不要不結(jié)合當(dāng)前業(yè)務(wù)場(chǎng)景，就隨意選用并發(fā)工具，可能導(dǎo)致系統(tǒng)性能更差

Do !!!

認(rèn)真閱讀官方文檔，理解并發(fā)工具適用場(chǎng)景及其各API的用法，并自行測(cè)試驗(yàn)證，最后再使用 并發(fā)bug本就不易復(fù)現(xiàn)， 多自行進(jìn)行性能壓力測(cè)試

下方二維碼關(guān)注我

技術(shù)草根，堅(jiān)持分享?編程，算法，架構(gòu)