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