# 前言 沒啥深入實踐的理論系同學，在使用併發工具時，總是認為把`HashMap`改為`ConcurrentHashMap`，就完美解決併發了呀。或者使用寫時複製的`CopyOnWriteArrayList`，效能更佳呀！技術言論雖然自由，但面對魔鬼面試官時，我們更在乎的是這些真的正確嗎？[整理了100+個Java專案視訊+原始碼+筆記](https://links.jianshu.com/go?to=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzIwNjg4MzY4NA%3D%3D%26mid%3D2247488785%26idx%3D2%26sn%3D9c3377625e118180fb36f1c251c581c2%26chksm%3D971b8b1aa06c020c4782c2e73ccdd2494c5429d02825401c1d19c1a2e17a4a0edf910e1f6c06%26token%3D637163543%26lang%3Dzh_CN%23rd) # 執行緒重用導致使用者資訊錯亂 生產環境中，有時獲取到的使用者資訊是別人的。檢視程式碼後，發現是使用了`ThreadLocal`快取獲取到的使用者資訊。 `ThreadLocal`適用於變數線上程間隔離，而在方法或類間共享的場景。 若使用者資訊的獲取比較昂貴（比如從DB查詢），則在`ThreadLocal`中快取比較合適。 問題來了，為什麼有時會出現使用者資訊錯亂？ ## 案例 使用ThreadLocal存放一個Integer值，代表需要線上程中儲存的使用者資訊，初始null。 先從ThreadLocal獲取一次值，然後把外部傳入的引數設定到ThreadLocal中，模擬從當前上下文獲取使用者資訊，隨後再獲取一次值，最後輸出兩次獲得的值和執行緒名稱。  固定思維認為，在設定使用者資訊前第一次獲取的值始終是null，但要清楚程式執行在Tomcat，執行程式的執行緒是Tomcat的工作執行緒，其基於執行緒池。 而執行緒池會重用固定執行緒，一旦執行緒重用，那麼很可能首次從ThreadLocal獲取的值是之前其他使用者的請求遺留的值。這時，ThreadLocal中的使用者資訊就是其他使用者的資訊。 ## 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工具存放資料時，需注意在程式碼執行完後，顯式清空設定的資料。 ## 解決方案 在finally程式碼塊顯式清除ThreadLocal中資料。即使新請求過來，使用了之前的執行緒，也不會獲取到錯誤的使用者資訊。 修正後代碼：  ThreadLocal利用獨佔資源的解決執行緒安全問題，若就是要資源線上程間共享怎麼辦？就需要用到執行緒安全的容器。 使用了執行緒安全的併發工具，並不代表解決了所有執行緒安全問題。 ## ThreadLocalRandom 可將其例項設定到靜態變數，在多執行緒下重用嗎？ current()的時候初始化一個初始化種子到執行緒，每次nextseed再使用之前的種子生成新的種子： ``` `UNSAFE.putLong(t = Thread.currentThread(), SEED, r = UNSAFE.getLong(t, SEED) + GAMMA);` ``` 如果你通過主執行緒呼叫一次current生成一個ThreadLocalRandom例項儲存，那麼其它執行緒來獲取種子的時候必然取不到初始種子，必須是每一個執行緒自己用的時候初始化一個種子到執行緒。 可以在nextSeed設定一個斷點看看： ``` `UNSAFE.getLong(Thread.currentThread(),SEED);` ``` # ConcurrentHashMap真的安全嗎？ 我們都知道ConcurrentHashMap是個執行緒安全的雜湊表容器，但它僅保證提供的原子性讀寫操作執行緒安全。 # 2.1 案例 有個含900個元素的Map，現在再補充100個元素進去，這個補充操作由10個執行緒併發進行。 開發人員誤以為使用ConcurrentHashMap就不會有執行緒安全問題，於是不加思索地寫出了下面的程式碼：在每一個執行緒的程式碼邏輯中先通過size方法拿到當前元素數量，計算ConcurrentHashMap目前還需要補充多少元素，並在日誌中輸出了這個值，然後通過putAll方法把缺少的元素新增進去。 為方便觀察問題，我們輸出了這個Map一開始和最後的元素個數。  訪問介面  分析日誌輸出可得： * 初始大小900符合預期，還需填充100個元素 * worker13執行緒查詢到當前需要填充的元素為49，還不是100的倍數 * 最後HashMap的總專案數是1549，也不符合填充滿1000的預期 ## bug 分析 ConcurrentHashMap就像是一個大籃子，現在這個籃子裡有900個桔子，我們期望把這個籃子裝滿1000個桔子，也就是再裝100個桔子。有10個工人來幹這件事兒，大家先後到崗後會計算還需要補多少個桔子進去，最後把桔子裝入籃子。 ConcurrentHashMap這籃子本身，可以確保多個工人在裝東西進去時，不會相互影響干擾，但無法確保工人A看到還需要裝100個桔子但是還未裝時，工人B就看不到籃子中的桔子數量。你往這個籃子裝100個桔子的操作不是原子性的，在別人看來可能會有一個瞬間籃子裡有964個桔子，還需要補36個桔子。 ConcurrentHashMap對外提供能力的限制： * 使用不代表對其的多個操作之間的狀態一致，是沒有其他執行緒在操作它的。如果需要確保需要手動加鎖 * 諸如size、isEmpty和containsValue等聚合方法，在併發下可能會反映ConcurrentHashMap的中間狀態。因此在併發情況下，這些方法的返回值只能用作參考，而不能用於流程控制。顯然，利用size方法計算差異值，是一個流程控制 * 諸如putAll這樣的聚合方法也不能確保原子性，在putAll的過程中去獲取資料可能會獲取到部分資料 ## 解決方案 整段邏輯加鎖：  只有一個執行緒查詢到需補100個元素，其他9個執行緒查詢到無需補，最後Map大小1000  既然使用ConcurrentHashMap還要全程加鎖，還不如使用HashMap呢？ 不完全是這樣。 ConcurrentHashMap提供了一些原子性的簡單複合邏輯方法，用好這些方法就可以發揮其威力。這就引申出程式碼中常見的另一個問題：在使用一些類庫提供的高階工具類時，開發人員可能還是按照舊的方式去使用這些新類，因為沒有使用其真實特性，所以無法發揮其威力。 # 知己知彼，百戰百勝 ## 案例 使用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`累加。 這樣在確保執行緒安全的情況下達到極致效能，且程式碼行數驟減。 ## 效能測試 使用StopWatch測試兩段程式碼的效能，最後的斷言判斷Map中元素的個數及所有V的和是否符合預期來校驗程式碼正確性  效能測試結果：  比使用鎖效能提升至少5倍。 ## computeIfAbsent高效能之道 Java的Unsafe實現的CAS。 它在JVM層確保寫入資料的原子性，比加鎖效率高： ``` `static final