多線程這塊很多人學(xué)完理論還是寫不出穩(wěn)的代碼——一上生產(chǎn)環(huán)境就出問(wèn)題數(shù)據(jù)對(duì)不上、接口變慢、日志亂成一團(tuán)。我見(jiàn)過(guò)不少項(xiàng)目的線上事故最后排查下來(lái)都是并發(fā)基礎(chǔ)沒(méi)打牢。這篇東西不打算從頭講什么是線程而是按我在實(shí)際項(xiàng)目里從“能跑”到“扛得住”的順序把創(chuàng)建方式、同步機(jī)制、線程池、并發(fā)容器和排查手段串起來(lái)講一遍。每個(gè)部分都有可以直接落地的代碼和參數(shù)參考也有我踩過(guò)的坑。適合已經(jīng)會(huì)寫簡(jiǎn)單Java程序、但一碰到多線程就心里沒(méi)底的開(kāi)發(fā)者。1. 多線程沒(méi)那么玄乎先搞懂執(zhí)行模型再寫代碼很多初學(xué)者一上來(lái)就去看各種鎖的源碼結(jié)果越看越糊涂。我自己的經(jīng)驗(yàn)是先搞清楚線程到底在計(jì)算機(jī)里怎么被執(zhí)行的再回頭看你寫的代碼很多問(wèn)題會(huì)豁然開(kāi)朗。1.1 線程是操作系統(tǒng)調(diào)度的執(zhí)行單元一個(gè)Java程序啟動(dòng)后main方法跑在主線程里。當(dāng)你手動(dòng)創(chuàng)建Thread或者通過(guò)線程池提交任務(wù)JVM會(huì)向操作系統(tǒng)申請(qǐng)新的執(zhí)行流。每個(gè)線程有自己的調(diào)用棧、程序計(jì)數(shù)器但共享同一個(gè)進(jìn)程的堆內(nèi)存和方法區(qū)。這意味著兩個(gè)線程可以同時(shí)讀同一個(gè)對(duì)象也可以同時(shí)去改它——這就是并發(fā)問(wèn)題的根源。從操作系統(tǒng)的視角看一個(gè)線程在執(zhí)行過(guò)程中會(huì)在三種狀態(tài)間切換運(yùn)行狀態(tài)占用CPU、就緒狀態(tài)等待CPU分配、阻塞狀態(tài)等待I/O、等待鎖、等待條件變量。Java線程狀態(tài)雖然分成了NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED六種但本質(zhì)上還是在描述同一件事。只是Java把“運(yùn)行”和“就緒”合并成了RUNNABLE讓你沒(méi)法直接看出線程是真正在跑還是在排隊(duì)等CPU。提示看線上線程狀態(tài)時(shí)如果大量線程卡在RUNNABLE且CPU居高不下多半是死循環(huán)或者真正的計(jì)算密集型任務(wù)如果大量線程卡在BLOCKED或WAITING則要重點(diǎn)排查鎖競(jìng)爭(zhēng)和資源等待。1.2 為什么多線程不一定更快一個(gè)常見(jiàn)的誤區(qū)是“線程開(kāi)得越多處理越快”。實(shí)際上每個(gè)線程的創(chuàng)建、上下文切換、銷毀都有成本。操作系統(tǒng)在切換線程時(shí)要保存和恢復(fù)寄存器、程序計(jì)數(shù)器、棧指針這個(gè)過(guò)程本身消耗CPU時(shí)間。如果你的任務(wù)是I/O密集型比如查數(shù)據(jù)庫(kù)、調(diào)遠(yuǎn)程接口、讀寫文件多線程能把等待I/O的時(shí)間利用起來(lái)如果任務(wù)是CPU密集型比如大量計(jì)算、復(fù)雜算法那線程數(shù)接近CPU核心數(shù)就夠了開(kāi)多了反而因?yàn)樯舷挛那袚Q變慢。舉個(gè)生活化的例子你去餐廳吃飯一個(gè)服務(wù)員可以同時(shí)接待多桌客人因?yàn)辄c(diǎn)菜、上菜之間有空閑等待時(shí)間。但如果每桌客人都要求服務(wù)員站在原地等菜出鍋那再多的服務(wù)員也沒(méi)用反而互相擋路。寫代碼也一樣得先想清楚你的任務(wù)是“等得多”還是“算得多”。我一般會(huì)在項(xiàng)目里先做一個(gè)簡(jiǎn)單的壓測(cè)用1個(gè)線程、核心線程數(shù)、2倍核心線程數(shù)分別跑同一批任務(wù)觀察吞吐量和響應(yīng)時(shí)間的變化。大多數(shù)情況下你會(huì)看到一個(gè)明顯的拐點(diǎn)那個(gè)拐點(diǎn)就是這臺(tái)機(jī)器上的合理線程數(shù)參考值。2. 創(chuàng)建線程的四種姿勢(shì)別只會(huì)繼承ThreadJava里創(chuàng)建線程的方式粗略分有四類繼承Thread、實(shí)現(xiàn)Runnable、實(shí)現(xiàn)Callable、使用線程池。這四種方式各有應(yīng)用場(chǎng)景但實(shí)際開(kāi)發(fā)里90%的并發(fā)任務(wù)我都會(huì)交給線程池剩下的用Callable或者Runnable包裝后提交。2.1 繼承Thread最直觀但別濫用public class MyThread extends Thread { Override public void run() { System.out.println(線程執(zhí)行中 Thread.currentThread().getName()); } } // 使用 MyThread t new MyThread(); t.start();這種方式簡(jiǎn)單直觀但有幾個(gè)硬傷Java是單繼承一旦繼承了Thread就不能再繼承其他類run()方法沒(méi)有返回值無(wú)法獲取執(zhí)行結(jié)果每次執(zhí)行任務(wù)都要新建線程無(wú)法復(fù)用。我在真實(shí)項(xiàng)目中基本不用這種方式只在寫一些測(cè)試Demo時(shí)圖方便才用。2.2 實(shí)現(xiàn)Runnable把任務(wù)和線程分開(kāi)public class Task implements Runnable { Override public void run() { // 具體業(yè)務(wù)邏輯 System.out.println(處理任務(wù)中...); } } Thread worker new Thread(new Task()); worker.start();實(shí)現(xiàn)Runnable的好處是把“要執(zhí)行的任務(wù)”和“執(zhí)行任務(wù)的線程”解耦。任務(wù)本身不知道也不關(guān)心自己跑在哪個(gè)線程上這樣任務(wù)可以被反復(fù)提交給不同線程。這是一個(gè)更符合面向?qū)ο笤O(shè)計(jì)的做法也是線程池出現(xiàn)之前的主流寫法。2.3 Callable和FutureTask需要返回結(jié)果時(shí)的選擇import java.util.concurrent.Callable; import java.util.concurrent.FutureTask; public class CallableTask implements CallableInteger { Override public Integer call() throws Exception { Thread.sleep(1000); return 42; } } FutureTaskInteger futureTask new FutureTask(new CallableTask()); Thread t new Thread(futureTask); t.start(); Integer result futureTask.get(); // 阻塞等待結(jié)果Callable的call()方法可以返回結(jié)果也可以拋出異常。但直接用FutureTask包一層再手動(dòng)起線程的方式本質(zhì)上還是沒(méi)解決線程復(fù)用問(wèn)題。我一般在需要同步拿結(jié)果的場(chǎng)景會(huì)用ExecutorService.submit()直接返回Future?既解決了線程復(fù)用又能拿結(jié)果代碼也簡(jiǎn)潔得多。2.4 線程池真正的主流生產(chǎn)方式關(guān)于線程池的細(xì)節(jié)后面有一整節(jié)單獨(dú)講這里先給一個(gè)直觀對(duì)比方式是否復(fù)用線程能否獲取結(jié)果適合場(chǎng)景繼承Thread否否僅學(xué)習(xí)演示Runnable否否簡(jiǎn)單異步任務(wù)CallableFutureTask否是需要結(jié)果的一次性任務(wù)線程池是是幾乎所有生產(chǎn)環(huán)境場(chǎng)景拿到一個(gè)需求先問(wèn)自己三個(gè)問(wèn)題這個(gè)任務(wù)需要馬上執(zhí)行嗎需要拿到執(zhí)行結(jié)果嗎任務(wù)是頻繁產(chǎn)生的嗎如果前兩個(gè)答案是“需要”第三個(gè)答案是“頻繁”那基本就直接走線程池不用猶豫。3. 共享變量的并發(fā)難題可見(jiàn)性、原子性、有序性線程創(chuàng)建方式搞清楚了真正的坑才開(kāi)始。多個(gè)線程一起讀寫共享變量時(shí)會(huì)出現(xiàn)三類問(wèn)題可見(jiàn)性、原子性、有序性。這三個(gè)詞聽(tīng)起來(lái)抽象但對(duì)應(yīng)到實(shí)際故障就非常具體。3.1 可見(jiàn)性你在另一個(gè)線程里改的值主線程看得見(jiàn)嗎先看這段代碼public class VisibilityDemo { private static boolean flag false; public static void main(String[] args) throws InterruptedException { Thread worker new Thread(() - { while (!flag) { // 空循環(huán)等待 } System.out.println(檢測(cè)到flag變化退出循環(huán)); }); worker.start(); Thread.sleep(1000); flag true; // 主線程修改變量 worker.join(); } }直覺(jué)上主線程睡了1秒后再把flag改成true子線程應(yīng)該馬上退出循環(huán)。但如果你在多核機(jī)器上跑這個(gè)程序可能永遠(yuǎn)不退出。原因在于每個(gè)線程會(huì)把變量從主內(nèi)存拷貝到自己的工作內(nèi)存也就是CPU高速緩存子線程一直在自己緩存里讀flag根本沒(méi)注意到主線程已經(jīng)改了主內(nèi)存里的值。解決辦法是給flag加上volatile關(guān)鍵字它保證了對(duì)變量的寫操作能立即刷回主內(nèi)存讀操作也會(huì)強(qiáng)制從主內(nèi)存讀取。但要注意volatile只保證可見(jiàn)性不保證原子性。比如多個(gè)線程同時(shí)對(duì)count做count即使count被聲明為volatile結(jié)果仍然是不準(zhǔn)確的。因?yàn)閏ount在底層是“讀取-修改-寫回”三步不具備原子性。3.2 原子性你以為是兩行代碼其實(shí)是好幾條指令count在字節(jié)碼層面包括GETSTATIC、IADD、PUTSTATIC等指令執(zhí)行過(guò)程中隨時(shí)可能被其他線程插進(jìn)來(lái)。要保證操作的原子性常用的手段有使用AtomicInteger、AtomicLong等原子類底層基于CASCompare-And-Swap實(shí)現(xiàn)使用synchronized或Lock給代碼塊加鎖使用LongAdder在高并發(fā)下比AtomicLong性能更好import java.util.concurrent.atomic.AtomicInteger; public class Counter { private final AtomicInteger count new AtomicInteger(0); public void increment() { count.incrementAndGet(); } public int getCount() { return count.get(); } }CAS的原理可以想象成“先檢查再更新”只有當(dāng)前內(nèi)存里的值仍然等于你預(yù)期的舊值時(shí)才把新值寫進(jìn)去否則就重試。這種方式不需要加鎖競(jìng)爭(zhēng)不激烈時(shí)性能很高但如果競(jìng)爭(zhēng)非常激烈CAS會(huì)頻繁重試性能反而下降。3.3 有序性編譯器和CPU可能不按代碼順序執(zhí)行為了優(yōu)化執(zhí)行效率編譯器和CPU可能對(duì)指令進(jìn)行重排序。在單線程環(huán)境下重排序不會(huì)影響最終結(jié)果因?yàn)闀?huì)保證結(jié)果一致。但在多線程環(huán)境下一個(gè)線程看到的執(zhí)行順序可能和代碼寫的順序完全不一樣。經(jīng)典的“雙重檢查鎖定”單例模式就踩過(guò)這個(gè)坑早期Java版本里未加volatile的單例字段可能導(dǎo)致其他線程拿到一個(gè)“構(gòu)造了一半”的對(duì)象。public class Singleton { private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }volatile在這里不僅保證了可見(jiàn)性還通過(guò)內(nèi)存屏障禁止了指令重排序確保instance被完整構(gòu)造后其他線程才能看到。3.4 synchronized和Lock哪種加鎖方式更適合你synchronized是JVM內(nèi)置的鎖機(jī)制使用簡(jiǎn)單不需要手動(dòng)解鎖代碼塊執(zhí)行完自動(dòng)釋放。JDK在后期對(duì)synchronized做了大量?jī)?yōu)化偏向鎖、輕量級(jí)鎖、自旋鎖大部分場(chǎng)景下性能已經(jīng)不輸Lock。Lock比如ReentrantLock則提供了更多功能可中斷鎖、公平鎖、超時(shí)等待、多個(gè)條件變量。我自己的選型標(biāo)準(zhǔn)很簡(jiǎn)單默認(rèn)先寫synchronized只有在需要“嘗試獲取鎖、獲取不到就算了”、需要“等待可中斷”、需要“公平隊(duì)列”時(shí)才換ReentrantLock。很多新手一上來(lái)就用ReentrantLock寫一堆lock()、unlock()忘記在finally里釋放直接導(dǎo)致死鎖。用synchronized至少不會(huì)犯這種低級(jí)錯(cuò)誤。4. 線程池怎么配才合理七個(gè)參數(shù)一個(gè)都不能拍腦袋線程池是Java并發(fā)里用得最多也最容易配錯(cuò)的組件。很多人直接用Executors.newFixedThreadPool(10)結(jié)果生產(chǎn)環(huán)境一出流量就出事。原因在于他們對(duì)背后的七個(gè)核心參數(shù)完全不了解。4.1 七參數(shù)拆解ThreadPoolExecutor的完整構(gòu)造參數(shù)如下public ThreadPoolExecutor( int corePoolSize, // 核心線程數(shù) int maximumPoolSize, // 最大線程數(shù) long keepAliveTime, // 非核心線程空閑存活時(shí)間 TimeUnit unit, // 存活時(shí)間單位 BlockingQueueRunnable workQueue, // 任務(wù)隊(duì)列 ThreadFactory threadFactory, // 線程工廠 RejectedExecutionHandler handler // 拒絕策略 )每個(gè)參數(shù)的作用corePoolSize即使線程空閑也保留的最小線程數(shù)。默認(rèn)情況下新任務(wù)到來(lái)時(shí)先創(chuàng)建核心線程去執(zhí)行核心線程忙不過(guò)來(lái)再往隊(duì)列里放。maximumPoolSize線程池允許的最大線程數(shù)。當(dāng)任務(wù)隊(duì)列也滿了的時(shí)候會(huì)繼續(xù)創(chuàng)建非核心線程直到達(dá)到這個(gè)上限。keepAliveTime unit非核心線程空閑多久后被回收。workQueue核心線程忙時(shí)任務(wù)先排隊(duì)。常用有界隊(duì)列ArrayBlockingQueue或者LinkedBlockingQueue。threadFactory創(chuàng)建線程的工廠可以給線程起名字方便排查問(wèn)題。handler任務(wù)隊(duì)列和最大線程都滿了之后的處理策略。4.2 什么是有界隊(duì)列、無(wú)界隊(duì)列、同步隊(duì)列LinkedBlockingQueue默認(rèn)不傳容量的話是“無(wú)界隊(duì)列”容量是Integer.MAX_VALUE。這意味著任務(wù)永遠(yuǎn)能排進(jìn)隊(duì)列永遠(yuǎn)不會(huì)觸發(fā)拒絕策略maximumPoolSize形同虛設(shè)。如果任務(wù)積壓過(guò)多內(nèi)存直接被打爆。這就是我不用newFixedThreadPool的原因——它的默認(rèn)隊(duì)列就是無(wú)界的。ArrayBlockingQueue需要指定容量是有界隊(duì)列。隊(duì)列滿后才會(huì)啟用非核心線程非核心線程也滿了才會(huì)觸發(fā)拒絕策略。SynchronousQueue不存任務(wù)直接把任務(wù)轉(zhuǎn)交給線程沒(méi)有空閑線程就創(chuàng)建新線程配合maximumPoolSize可以做到“臨時(shí)擴(kuò)容”。一個(gè)比較穩(wěn)的經(jīng)驗(yàn)值CPU密集型任務(wù)corePoolSize設(shè)為CPU核數(shù)加1或等于核數(shù)I/O密集型任務(wù)corePoolSize設(shè)為核心數(shù)的2倍以上具體要看阻塞比例我之前專門用“線程耗時(shí)/CPU計(jì)算耗時(shí)比”估算過(guò)。4.3 拒絕策略怎么選JDK內(nèi)置了四種拒絕策略策略行為AbortPolicy直接拋出RejectedExecutionException會(huì)打斷業(yè)務(wù)CallerRunsPolicy提交任務(wù)的那個(gè)線程自己執(zhí)行適合削峰DiscardPolicy直接丟棄不提示慎用DiscardOldestPolicy丟棄隊(duì)列里最老的任務(wù)再嘗試提交新任務(wù)我在業(yè)務(wù)系統(tǒng)里一般用CallerRunsPolicy。它的好處是任務(wù)不丟而且慢下來(lái)的響應(yīng)會(huì)反向壓迫上游限流不會(huì)讓線程池瞬間被擊穿。但要注意如果當(dāng)前提交任務(wù)的是請(qǐng)求線程那么這個(gè)請(qǐng)求會(huì)阻塞在線程池的任務(wù)執(zhí)行里接口響應(yīng)時(shí)間會(huì)變長(zhǎng)。所以這個(gè)策略適合內(nèi)部任務(wù)不適合直接用在計(jì)算開(kāi)銷極大的請(qǐng)求鏈路中。4.4 線程池的優(yōu)雅關(guān)閉和線程泄漏很多項(xiàng)目上線后發(fā)觀察一次接口就沒(méi)反應(yīng)了。絕大多數(shù)情況是線程池沒(méi)正確關(guān)閉或者任務(wù)里拋了異常導(dǎo)致線程不正?；厥?。shutdown()會(huì)讓線程池等已提交任務(wù)執(zhí)行完才關(guān)shutdownNow()會(huì)嘗試中斷正在執(zhí)行的任務(wù)并返回等待隊(duì)列中的任務(wù)列表。另一個(gè)容易忽略的問(wèn)題是線程池里的線程如果一直處于WAITING狀態(tài)比如調(diào)了阻塞隊(duì)列的take方法且沒(méi)有中斷機(jī)制shutdownNow()也未必能順利回收。這種情況很隱蔽排查的時(shí)候要結(jié)合線程?？纯茨切┚€程到底卡在哪一行代碼。5. 并發(fā)容器與典型業(yè)務(wù)場(chǎng)景生產(chǎn)消費(fèi)者模型實(shí)戰(zhàn)并發(fā)問(wèn)題不只會(huì)發(fā)生在自己寫的變量上JDK自帶的集合類很多也不是線程安全的。用錯(cuò)集合幾乎是一秒鐘就踩雷的事情。5.1 HashMap、ArrayList為什么在多線程下會(huì)出問(wèn)題HashMap在并發(fā)擴(kuò)容時(shí)早期版本會(huì)出現(xiàn)死循環(huán)雖然JDK 8后改成尾插法緩解了這個(gè)問(wèn)題但仍然可能丟數(shù)據(jù)、覆蓋數(shù)據(jù)。ArrayList在多線程同時(shí)add時(shí)可能導(dǎo)致數(shù)組越界或元素丟失。這些問(wèn)題的根源在于它們的內(nèi)部狀態(tài)在無(wú)同步的情況下被多個(gè)線程同時(shí)改寫。需要線程安全的場(chǎng)景可以用ConcurrentHashMap分段鎖/CAS優(yōu)化讀多寫少的首選CopyOnWriteArrayList寫時(shí)復(fù)制適合讀多寫極少的場(chǎng)景Collections.synchronizedList粗暴地給所有方法加鎖性能一般BlockingQueue族本身就是線程安全的隊(duì)列適合生產(chǎn)消費(fèi)者模型5.2 BlockingQueue實(shí)現(xiàn)生產(chǎn)消費(fèi)者生產(chǎn)消費(fèi)者模型是并發(fā)編程最經(jīng)典的場(chǎng)景它有幾種不同的構(gòu)建方式但核心思想都是把“生產(chǎn)”和“消費(fèi)”解耦。隊(duì)列放在中間充當(dāng)緩沖區(qū)兩邊都不需要知道對(duì)方的存在。import java.util.concurrent.BlockingQueue; import java.util.concurrent.LinkedBlockingQueue; public class TaskQueue { private final BlockingQueueRunnable queue new LinkedBlockingQueue(100); public void produce(Runnable task) { try { queue.put(task); System.out.println(生產(chǎn)任務(wù) task); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } public Runnable consume() { try { return queue.take(); // 隊(duì)列為空時(shí)阻塞等待 } catch (InterruptedException e) { Thread.currentThread().interrupt(); return null; } } }這里用put和take而不是add和poll是因?yàn)榍皟烧咦詭ё枞Ч?duì)列滿了生產(chǎn)者會(huì)等待隊(duì)列空了消費(fèi)者會(huì)等待。這比自己在外面寫while (queue.isEmpty())輪詢要靠譜得多也省CPU。5.3 一個(gè)完整的多線程任務(wù)分發(fā)Demo把前面講的東西組合一下寫一個(gè)簡(jiǎn)化版的異步任務(wù)分發(fā)器import java.util.concurrent.*; public class TaskDispatcher { private final ThreadPoolExecutor executor; public TaskDispatcher() { ExecutorService baseExecutor new ThreadPoolExecutor( 4, 8, 60, TimeUnit.SECONDS, new ArrayBlockingQueue(200), new NamedThreadFactory(task-dispatcher), new ThreadPoolExecutor.CallerRunsPolicy() ); this.executor (ThreadPoolExecutor) baseExecutor; } public Future? submit(Runnable task) { return executor.submit(task); } public void shutdownGracefully() { executor.shutdown(); try { if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { executor.shutdownNow(); } } catch (InterruptedException e) { executor.shutdownNow(); } } static class NamedThreadFactory implements ThreadFactory { private final String prefix; private int count 0; NamedThreadFactory(String prefix) { this.prefix prefix; } Override public Thread newThread(Runnable r) { return new Thread(r, prefix - (count)); } } }用的時(shí)候只需要TaskDispatcher dispatcher new TaskDispatcher(); dispatcher.submit(() - { // 模擬耗時(shí)操作 }); dispatcher.shutdownGracefully();這只是最基礎(chǔ)的任務(wù)分發(fā)但已經(jīng)夠看懂線程池怎么在一個(gè)真實(shí)模塊里工作了。下一步可以做的擴(kuò)展包括任務(wù)結(jié)果回調(diào)用Future或者CompletableFuture、失敗重試、定時(shí)調(diào)度等。6. 黑盒定位線程問(wèn)題排查工具與經(jīng)驗(yàn)代碼寫完了人總得面對(duì)生產(chǎn)環(huán)境。線程問(wèn)題最頭疼的地方在于它不是每次都能復(fù)現(xiàn)同一個(gè)接口偶爾慢一次數(shù)據(jù)偶爾錯(cuò)一筆。這時(shí)候靠直覺(jué)看代碼不如靠工具看真實(shí)運(yùn)行狀態(tài)。6.1 jstack看線程狀態(tài)和鎖等待jstack pid是排查線程問(wèn)題的第一把鑰匙。執(zhí)行后會(huì)輸出進(jìn)程里所有線程的棧信息重點(diǎn)關(guān)注BLOCKED和WAITING的線程。如果看到大量線程卡在同一個(gè)對(duì)象上并且stack里帶著鎖信息說(shuō)明發(fā)生了鎖競(jìng)爭(zhēng)。有一次我們線上出現(xiàn)了接口超時(shí)我打了一份jstack發(fā)現(xiàn)幾十個(gè)線程卡在同一個(gè)數(shù)據(jù)庫(kù)連接池獲取連接的方法上。正常邏輯是連接池沒(méi)連接了應(yīng)該等待并超時(shí)但某個(gè)連接沒(méi)被正確歸還導(dǎo)致所有線程都堵在那。這個(gè)問(wèn)題如果只看代碼根本發(fā)現(xiàn)不了是因?yàn)檫B接池復(fù)用邏輯里某個(gè)分支沒(méi)有執(zhí)行finally中的歸還操作。提示分析jstack時(shí)重點(diǎn)關(guān)注線程名字。線程池里自己起名字的線程一眼就能看出是哪個(gè)池子的問(wèn)題不自定義線程名的排查成本會(huì)高很多。6.2 死鎖的檢測(cè)與預(yù)防死鎖的產(chǎn)生需要四個(gè)條件同時(shí)成立互斥、持有并等待、不可剝奪、循環(huán)等待。實(shí)際編碼里最常見(jiàn)的原因是“鎖的順序不一致”——線程A先拿鎖1再拿鎖2線程B先拿鎖2再拿鎖1兩者剛好交錯(cuò)互相等對(duì)方釋放鎖。死鎖的檢測(cè)可以借助jstack看到類似“Found one Java-level deadlock”的提示。但要等到檢測(cè)到就已經(jīng)晚了最好在代碼層面做好預(yù)防加鎖的順序全局一致比如統(tǒng)一按某個(gè)業(yè)務(wù)ID排序后再加鎖使用tryLock(timeout)給獲取鎖加超時(shí)拿不到就放棄釋放已持有的鎖盡量減少鎖的范圍把資源競(jìng)爭(zhēng)盡可能集中到最小臨界區(qū)6.3 CPU飆高和線程泄漏的排查思路線程泄漏不是一次性的問(wèn)題而是“只增不減”的隱性問(wèn)題。常見(jiàn)原因有沒(méi)關(guān)閉線程池、任務(wù)異常導(dǎo)致線程卡死、第三方庫(kù)內(nèi)部緩存線程不被回收。排查時(shí)用jstack看線程數(shù)量變化再用top -H -p pid看具體線程CPU占用。如果一個(gè)線程長(zhǎng)期占滿一個(gè)CPU核心多半是死循環(huán)或者熱點(diǎn)計(jì)算。CPU飆高的處理思路先抓線程快照定位到線程ID再把線程ID轉(zhuǎn)成十六進(jìn)制在jstack輸出里搜到對(duì)應(yīng)線程?？此降自谂苁裁创a。有時(shí)候你會(huì)發(fā)現(xiàn)是一個(gè)正則表達(dá)式在回溯匹配有時(shí)候是HashMap.get在一個(gè)超大鏈表上遍歷。這些問(wèn)題的共同點(diǎn)是“看起來(lái)只是數(shù)據(jù)量大了一點(diǎn)但執(zhí)行時(shí)間突然失控”。6.4 日志和壓測(cè)輔助驗(yàn)證排查問(wèn)題最好能先恢復(fù)現(xiàn)場(chǎng)的近似條件。我的習(xí)慣是寫一個(gè)小的復(fù)現(xiàn)程序用線程池并發(fā)調(diào)目標(biāo)方法配合不同參數(shù)組合看是否能穩(wěn)定復(fù)現(xiàn)問(wèn)題。如果能復(fù)現(xiàn)就在關(guān)鍵代碼段打印日志和時(shí)間戳定位耗時(shí)分布。這個(gè)方法聽(tīng)起來(lái)笨但比在線上改代碼打日志要安全得多。壓測(cè)時(shí)還有一個(gè)容易被忽略的點(diǎn)測(cè)試機(jī)器的CPU核數(shù)和生產(chǎn)者在線上的核數(shù)相差很大配置的線程池參數(shù)需要按機(jī)器規(guī)格單獨(dú)調(diào)整不能直接沿用測(cè)試環(huán)境的配置。我自己就吃過(guò)這個(gè)虧拿到一個(gè)32核的壓測(cè)結(jié)果后往8核生產(chǎn)環(huán)境一配效果完全兩碼事。7. 常見(jiàn)誤區(qū)與我的實(shí)操判斷最后把多線程實(shí)踐里反復(fù)出現(xiàn)的一些誤區(qū)集中列一下都是我在代碼評(píng)審和排障過(guò)程中實(shí)際看到過(guò)的。7.1 volatile真的能保證線程安全嗎不能。我經(jīng)?？吹接腥私o普通變量加上volatile就說(shuō)它是線程安全的。volatile能保證可見(jiàn)性和一定程度的順序性但對(duì)于復(fù)合操作如count、list.add()、map.put()這種組合動(dòng)作無(wú)能為力。它適合的場(chǎng)景很窄一個(gè)線程寫、多個(gè)線程讀的狀態(tài)開(kāi)關(guān)或者作為“先行發(fā)生”規(guī)則的觸發(fā)點(diǎn)。7.2 線程數(shù)是不是越多越好不是。前面說(shuō)過(guò)上下文切換有成本。線程數(shù)增加到一定程度后每個(gè)線程的執(zhí)行效率會(huì)下降整體吞吐量可能不再增長(zhǎng)甚至下降。從資源角度看每開(kāi)一個(gè)線程默認(rèn)棧大小可能就要占用幾百KB到1MB內(nèi)存無(wú)限開(kāi)線程遲早遇到內(nèi)存或者句柄限制。我之前見(jiàn)過(guò)一個(gè)項(xiàng)目每接收一個(gè)外部通知就手動(dòng)new Thread(...).start()一天上千萬(wàn)次調(diào)用直接導(dǎo)致線程數(shù)量爆炸。后面改成線程池加限流CPU占用下降了一截穩(wěn)定性也上來(lái)了。7.3 synchronized和ReentrantLock到底怎么選如果團(tuán)隊(duì)沒(méi)有特殊要求我會(huì)優(yōu)先使用synchronized。理由前面說(shuō)過(guò)了不容易漏解鎖語(yǔ)義清楚。ReentrantLock在多路分支需要手動(dòng)解鎖的復(fù)雜場(chǎng)景用起來(lái)很容易出錯(cuò)尤其是有多個(gè)return語(yǔ)句的方法。當(dāng)然如果你確實(shí)需要“公平鎖”或者“可中斷等待”那ReentrantLock不可替代。7.4 寫并發(fā)代碼時(shí)最重要的三個(gè)習(xí)慣第一共享變量的范圍盡量縮小。能用局部變量就不要放到成員變量能用參數(shù)傳遞就不要做全局狀態(tài)。第二所有共享資源的訪問(wèn)統(tǒng)一走同步手段不要有的地方加鎖有的地方裸讀。第三給線程起好名字給鎖操作加上注釋和邊界說(shuō)明。這是給自己減少排查成本也是給組里后人留活路。多線程的代碼寫起來(lái)并不難難的是讓它在高并發(fā)下穩(wěn)定運(yùn)行。把自己寫的線程池參數(shù)、加鎖邏輯、隊(duì)列選型都想清楚再配合故障排查手段大部分并發(fā)問(wèn)題都能在萌芽階段被摁住。