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