做系統(tǒng)的時(shí)候總有一類需求繞不開(kāi)每隔幾秒做點(diǎn)事情輪詢數(shù)據(jù)庫(kù)狀態(tài)、刷新緩存、發(fā)送心跳包或者界面上憋著一個(gè)不斷跳動(dòng)的倒計(jì)時(shí)。大多數(shù)人第一反應(yīng)是while Thread.sleep()講究一點(diǎn)的會(huì)用Timer結(jié)果線上踩了幾個(gè)坑之后才愿意回頭把多線程基礎(chǔ)補(bǔ)扎實(shí)。這篇文章就拿“計(jì)時(shí)器”當(dāng)案例帶你把Java多線程從“能跑”走到“能用”覆蓋線程創(chuàng)建、中斷、可見(jiàn)性、原子性、協(xié)作等待、定時(shí)調(diào)度這些核心點(diǎn)。計(jì)時(shí)器這個(gè)例子雖然小但它能把JMM的內(nèi)存可見(jiàn)性、線程協(xié)作的阻塞喚醒、定時(shí)任務(wù)的工程選型全串起來(lái)特別適合剛學(xué)完基礎(chǔ)語(yǔ)法、正卡在“線程到底怎么落地”這一關(guān)的同學(xué)反復(fù)拆解。后面所有代碼你都能直接復(fù)制到本地跑改幾個(gè)參數(shù)就能用到自己的項(xiàng)目里。1. 為什么拿“計(jì)時(shí)器”練多線程而不是更復(fù)雜的東西1.1 計(jì)時(shí)器天然要求“時(shí)間推進(jìn)”和“主流程”分離你寫(xiě)一個(gè)下單頁(yè)面的倒計(jì)時(shí)主導(dǎo)線程在等用戶輸入界面上的數(shù)字卻要一秒一秒往前走。這兩件事如果寫(xiě)成同一段函數(shù)誰(shuí)都沒(méi)法干活。把“計(jì)時(shí)推進(jìn)”抽成一個(gè)獨(dú)立線程讓它在后臺(tái)每秒更新一次狀態(tài)主線程該干嘛干嘛這就是并發(fā)編程最典型的職責(zé)拆分。很多新手寫(xiě)時(shí)序邏輯時(shí)一上來(lái)就卡在這里不知道哪些東西該放進(jìn)線程體哪些該留在主流程。計(jì)時(shí)器恰好把邊界畫(huà)得清清楚楚——推進(jìn)動(dòng)作進(jìn)線程業(yè)務(wù)操作留在主流程兩個(gè)世界通過(guò)共享狀態(tài)對(duì)話。1.2 它能干凈地復(fù)現(xiàn)線程三大核心問(wèn)題線程學(xué)起來(lái)抽象是因?yàn)槿髥?wèn)題通常散落在這篇文章里、那篇例子里很難真實(shí)感受到“為什么我的多線程程序結(jié)果不對(duì)”。計(jì)時(shí)器可以把它們?nèi)科毓饩€程安全性多個(gè)線程同時(shí)讀改寫(xiě)剩余秒數(shù)不加同步會(huì)出現(xiàn)莫名其妙的值。可見(jiàn)性一個(gè)線程修改了運(yùn)行標(biāo)志另一個(gè)線程看不見(jiàn)程序不退出。線程協(xié)作暫停、恢復(fù)、停止本質(zhì)是多個(gè)線程之間協(xié)調(diào)推進(jìn)節(jié)奏得靠wait/notify或者更高級(jí)的鎖工具。也就是說(shuō)一個(gè)計(jì)時(shí)器做出來(lái)你基本已經(jīng)過(guò)了“紙上談兵”的階段直接見(jiàn)過(guò)并發(fā)編程最常見(jiàn)的三個(gè)坑。這也是我推薦進(jìn)階階段用這個(gè)案例練手的原因覆蓋面廣代碼量又不會(huì)大到勸退。1.3 這個(gè)案例適合什么人、需要哪些基礎(chǔ)如果你是那個(gè)“能寫(xiě)完整類但沒(méi)系統(tǒng)碰過(guò)線程”的人最合適。建議先熟悉Thread和Runnable兩個(gè)基本接口知道sleep會(huì)讓線程暫時(shí)停下知道synchronized可以給方法加鎖。不理解細(xì)節(jié)沒(méi)關(guān)系文里用到的地方都會(huì)解釋得比較細(xì)但要能跟著代碼跑。我還遇到不少工作了兩三年、平時(shí)只用過(guò)Executors封裝類的朋友并不知道定時(shí)任務(wù)底層還有這么多講究這篇對(duì)他們同樣值得讀。基礎(chǔ)沒(méi)打牢的時(shí)候直接去看并發(fā)框架只會(huì)覺(jué)得“好像會(huì)用不知道原理”本項(xiàng)目正好補(bǔ)齊中間斷層。2. 第一個(gè)能跑的計(jì)時(shí)器Thread繼承與中斷陷阱2.1 先跑起來(lái)直接繼承Thread實(shí)現(xiàn)每秒計(jì)時(shí)先來(lái)一個(gè)能運(yùn)行的版本感受一下最原始的姿態(tài)。public class TimerThread extends Thread { private int count 0; Override public void run() { try { while (true) { Thread.sleep(1000); count; System.out.println(已過(guò) count 秒); } } catch (InterruptedException e) { System.out.println(計(jì)時(shí)器線程被中斷退出); } } public static void main(String[] args) throws InterruptedException { TimerThread timer new TimerThread(); timer.start(); Thread.sleep(5000); System.out.println(主線程休息完畢嘗試停止計(jì)時(shí)器); timer.interrupt(); } }這段代碼描述的是最樸素的模型一個(gè)獨(dú)立線程負(fù)責(zé)計(jì)時(shí)主線程五秒后發(fā)出中斷信號(hào)讓計(jì)時(shí)線程結(jié)束。運(yùn)行一下你會(huì)發(fā)現(xiàn)interrupt()之后線程確實(shí)退出了主線程也繼續(xù)走完。但這里藏著一個(gè)巨大的隱患我在很多生產(chǎn)代碼里都見(jiàn)過(guò)InterruptedException被當(dāng)成“暫停一下再繼續(xù)”的信號(hào)。真正的中斷語(yǔ)義是“有人請(qǐng)求你停止當(dāng)前工作快點(diǎn)響應(yīng)”你要是把異常悄悄吞掉整個(gè)線程可能永遠(yuǎn)不會(huì)退出。2.2 Thread和Runnable怎么選換用Runnable改造上面例子繼承Thread能跑但屬于“反面典型”。原因用兩句話能說(shuō)清楚任務(wù)代碼和線程生命周期耦合在一起你沒(méi)法把這個(gè)計(jì)時(shí)邏輯拿到線程池里復(fù)用一個(gè)類繼承了Thread就失去了繼承其他類的機(jī)會(huì)。改成Runnable才是正確姿勢(shì)。public class TimerTask implements Runnable { private int count 0; Override public void run() { try { while (!Thread.currentThread().isInterrupted()) { Thread.sleep(1000); count; System.out.println(已過(guò) count 秒); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); System.out.println(計(jì)時(shí)任務(wù)被中斷當(dāng)前計(jì)數(shù) count); } } public static void main(String[] args) throws InterruptedException { Thread worker new Thread(new TimerTask(), 計(jì)時(shí)器線程); worker.start(); Thread.sleep(5000); worker.interrupt(); } }這里我把Thread和Runnable的職責(zé)分開(kāi)看Thread是工人Runnable是工作內(nèi)容。工人可以換工作內(nèi)容不會(huì)變。你之后想把同樣的計(jì)時(shí)邏輯丟給線程池執(zhí)行直接executor.submit(new TimerTask())就行不需要再造一個(gè)線程。很多老項(xiàng)目里那種“一個(gè)業(yè)務(wù)一個(gè)Thread子類”的寫(xiě)法改造成本高就是早期沒(méi)有分清楚這兩個(gè)角色?，F(xiàn)在在團(tuán)隊(duì)里看到這種代碼我通常建議趁早重構(gòu)越晚越被動(dòng)。2.3 中斷標(biāo)志與sleepInterruptedException不是用來(lái)吞的上面代碼里的Thread.currentThread().interrupt()這行新手很容易漏掉。要理解它得先搞清楚一件事Thread.sleep()在被中斷時(shí)會(huì)直接拋出InterruptedException同時(shí)把線程的中斷狀態(tài)清掉。聽(tīng)起來(lái)沒(méi)問(wèn)題但如果你不手動(dòng)再設(shè)置一次中斷標(biāo)志線程后續(xù)即使還想處理中斷信號(hào)也沒(méi)辦法通過(guò)isInterrupted()感知到曾經(jīng)有中斷發(fā)生過(guò)。換句話說(shuō)catch塊里如果不補(bǔ)回標(biāo)志位等于把“有人喊你停下”這個(gè)消息弄丟了。我見(jiàn)過(guò)最坑的版本是這樣的catch (InterruptedException e) { /* 什么都不做 */ }外面用while (true)包住。你以為中斷能停線程實(shí)際它會(huì)一直空轉(zhuǎn)。排查這種問(wèn)題最費(fèi)時(shí)間因?yàn)榇a看起來(lái)“沒(méi)錯(cuò)”甚至沒(méi)人會(huì)懷疑sleep被中斷后標(biāo)志位會(huì)被清掉。所以我的習(xí)慣是只要捕獲了InterruptedException第一行就寫(xiě)Thread.currentThread().interrupt()要么直接return退出任務(wù)兩種方式都保證標(biāo)志位不丟。3. 讓計(jì)時(shí)器能真正“停下來(lái)”volatile標(biāo)志位3.1 為什么不能用廢棄的stop方法講停止線程很多人第一反應(yīng)是“不是有個(gè)stop()方法嗎”這個(gè)方法確實(shí)存在但它已經(jīng)被標(biāo)記為廢棄生產(chǎn)環(huán)境千萬(wàn)別碰。stop()的粗暴程度相當(dāng)于直接拔電源它不管當(dāng)前代碼執(zhí)行到哪一行、鎖有沒(méi)有釋放、資源有沒(méi)有清理直接讓線程帶著殘局消失。最典型的問(wèn)題是假如線程正在寫(xiě)一筆訂單數(shù)據(jù)寫(xiě)到一半被stop()剩下那半條數(shù)據(jù)就永久留在內(nèi)存里了其他線程讀到的狀態(tài)完全不可預(yù)測(cè)。所以Java官方給的態(tài)度很明確停止一個(gè)線程得靠協(xié)作不是靠暴力。協(xié)作的意思是別的線程發(fā)出“請(qǐng)停止”的請(qǐng)求目標(biāo)線程在合適的檢查點(diǎn)自行退出。3.2 用volatile布爾變量實(shí)現(xiàn)協(xié)作式停止最容易寫(xiě)也最實(shí)用的協(xié)作方式是加一個(gè)運(yùn)行開(kāi)關(guān)。public class VolatileTimer implements Runnable { private volatile boolean running true; Override public void run() { int count 0; while (running) { try { Thread.sleep(1000); count; System.out.println(已過(guò) count 秒); } catch (InterruptedException e) { Thread.currentThread().interrupt(); System.out.println(收到中斷準(zhǔn)備退出); return; } } System.out.println(計(jì)時(shí)器正常退出); } public void stop() { this.running false; } }這個(gè)版本的思路很清晰stop()方法把running設(shè)為false線程檢查到之后就退出循環(huán)。這里必須加上volatile否則一定會(huì)遇到“運(yùn)行了半天還是停不下來(lái)”的靈異問(wèn)題。原理是這樣的在多線程環(huán)境下每個(gè)線程都可能把共享變量緩存在自己的工作內(nèi)存里A線程改了running的值B線程未必能立刻看到最新值它可能一直用舊緩存繼續(xù)跑。volatile保證running的修改對(duì)任何線程都可見(jiàn)相當(dāng)于在所有讀寫(xiě)點(diǎn)之間建立一條直通通道。這段代碼里我保留了中斷處理。其實(shí)有了volatile就算sleep被打斷也不影響退出邏輯但保留中斷處理能讓代碼更健壯。實(shí)戰(zhàn)中建議標(biāo)志位和中斷兩條腿走路因?yàn)橛行┳枞僮鞅热绲却i、等待IO只認(rèn)中斷信號(hào)不認(rèn)你的running標(biāo)志。3.3 volatile只解決一半問(wèn)題可見(jiàn)性不等于原子性volatile好用但不能神話。它只解決“我對(duì)變量的修改別人能看見(jiàn)”并不解決“多個(gè)線程同時(shí)改寫(xiě)一個(gè)變量時(shí)的競(jìng)爭(zhēng)問(wèn)題”。拿計(jì)時(shí)器舉例如果兩個(gè)線程同時(shí)對(duì)count執(zhí)行count就崩潰了。因?yàn)閏ount實(shí)際上是“讀取-加一-寫(xiě)回”三步兩個(gè)人同時(shí)讀到同一個(gè)舊值各自加一再寫(xiě)回結(jié)果只加了一次。volatile根本不攔這種競(jìng)爭(zhēng)。遇到需要“讀改寫(xiě)”的共享狀態(tài)就得靠原子類或者加鎖。這也是為什么下一章要引入AtomicInteger。4. 給計(jì)時(shí)器加上暫停、恢復(fù)、重置原子類與wait/notify4.1 倒計(jì)時(shí)場(chǎng)景重新設(shè)計(jì)現(xiàn)在我把例子升級(jí)一下做一個(gè)支持“暫停、恢復(fù)、重置、停止”的倒計(jì)時(shí)器。這個(gè)版本比單純秒表實(shí)用得多也更貼近真實(shí)業(yè)務(wù)里的交互場(chǎng)景。設(shè)計(jì)數(shù)據(jù)模型時(shí)有兩個(gè)共享狀態(tài)需要處理剩余秒數(shù)多線程會(huì)讀會(huì)寫(xiě)用AtomicInteger保證原子更新。運(yùn)行狀態(tài)暫停、運(yùn)行、停止用volatile boolean控制可見(jiàn)性。同時(shí)線程在暫停狀態(tài)下不能傻等要主動(dòng)讓出CPU這里用wait/notify配合一個(gè)pauseLock對(duì)象來(lái)實(shí)現(xiàn)。import java.util.concurrent.atomic.AtomicInteger; public class CountdownTimer { private final AtomicInteger remaining new AtomicInteger(0); private final Object pauseLock new Object(); private volatile boolean running false; private volatile boolean paused false; private Thread workerThread; public void start(int seconds) { if (running) { System.out.println(計(jì)時(shí)器已經(jīng)在運(yùn)行請(qǐng)先停止再啟動(dòng)); return; } remaining.set(seconds); running true; paused false; workerThread new Thread(this::run, countdown-worker); workerThread.start(); } public void pause() { paused true; } public void resume() { if (!paused) return; paused false; synchronized (pauseLock) { pauseLock.notifyAll(); } } public void stop() { running false; synchronized (pauseLock) { pauseLock.notifyAll(); } } private void run() { while (running) { while (paused) { synchronized (pauseLock) { try { pauseLock.wait(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } } } int current remaining.get(); System.out.println(剩余秒數(shù) current); if (current 0) { System.out.println(倒計(jì)時(shí)結(jié)束); running false; return; } try { Thread.sleep(1000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } remaining.decrementAndGet(); } } }調(diào)用方式也很直觀CountdownTimer timer new CountdownTimer(); timer.start(5); Thread.sleep(2000); timer.pause(); Thread.sleep(3000); timer.resume(); Thread.sleep(5000); timer.stop();原子類在這里的價(jià)值就是讓remaining.decrementAndGet()這個(gè)“讀-改-寫(xiě)”動(dòng)作變成一步到位不再擔(dān)心兩個(gè)線程同時(shí)減一導(dǎo)致丟數(shù)據(jù)。真正寫(xiě)業(yè)務(wù)代碼的時(shí)候只要涉及計(jì)數(shù)、序號(hào)、開(kāi)關(guān)這種單值狀態(tài)優(yōu)先考慮原子類簡(jiǎn)單高效不用背上Lock的復(fù)雜心智負(fù)擔(dān)。4.2 wait/notify協(xié)作要注意的三類問(wèn)題第一次寫(xiě)wait/notify的人十有八九會(huì)踩到下面幾個(gè)坑我先替你排掉。第一wait()必須在持有鎖的代碼塊里調(diào)用否則直接拋IllegalMonitorStateException。這個(gè)設(shè)計(jì)是為了保證wait檢查條件與釋放鎖之間是原子操作避免“線程將要等待時(shí)另一個(gè)線程已經(jīng)完成喚醒”的競(jìng)態(tài)。所以上面代碼里每次調(diào)用wait()前都會(huì)synchronized (pauseLock)。第二notify只能喚醒正在等待的線程喚醒后它還要重新?lián)屾i才能繼續(xù)執(zhí)行。我看到新手寫(xiě)的暫?；謴?fù)邏輯經(jīng)常只記得paused false忘了notifyAll()結(jié)果線程在wait()里睡死過(guò)去怎么點(diǎn)恢復(fù)都沒(méi)反應(yīng)。上面代碼里resume()和stop()兩個(gè)方法都主動(dòng)做了notifyAll()就是為了把這個(gè)“睡死”的線程撈起來(lái)。第三暫停語(yǔ)義和剩余秒數(shù)要小心邊界。倒計(jì)時(shí)到0的判斷必須放在打印之后、繼續(xù)循環(huán)之前不然可能出現(xiàn)“明明顯示0秒還在繼續(xù)打印-1秒”的尷尬情況。我在上面run()里把判斷放在打印后面就是這樣考慮的先輸出當(dāng)前值再判斷是否結(jié)束邏輯走到decrementAndGet()時(shí)剩余秒數(shù)已經(jīng)不是屏幕上顯示的那個(gè)值了正好形成完整的一秒節(jié)奏。4.3 為什么我推薦先把wait/notify練熟再上鎖工具現(xiàn)在很多同學(xué)上來(lái)就直接用ReentrantLock和Condition覺(jué)得wait/notify太原始。我的觀點(diǎn)相反Object自帶的wait/notify雖然簡(jiǎn)陋但它能逼你理解“條件、鎖、阻塞、喚醒”四個(gè)概念的本質(zhì)。Condition只是把同一套語(yǔ)義包裝得更順手你如果連wait為什么要進(jìn)synchronized塊、為什么用while而不是if來(lái)檢查條件都沒(méi)想明白換Condition照樣寫(xiě)出死鎖。破案快的秘訣不是在高級(jí)工具里找答案而是把底層機(jī)制摸清。用了兩三次wait/notify之后你再看Condition源碼基本就是翻譯題了。5. 定時(shí)任務(wù)的工程化選擇Timer與ScheduledExecutorService5.1 Timer為什么通常被勸退看到這里你已經(jīng)能寫(xiě)一個(gè)相當(dāng)靈活的計(jì)時(shí)器了。但如果回到真實(shí)項(xiàng)目中直接用while sleep或者自己造輪子并不是最高效的方案。Java自帶java.util.Timer可以做定時(shí)調(diào)度但實(shí)戰(zhàn)里我?guī)缀醪煌扑]原因有兩條。第一Timer內(nèi)部只有一個(gè)工作線程。你同時(shí)注冊(cè)多個(gè)TimerTask它們?nèi)谝粭l線程里排隊(duì)執(zhí)行。任何一個(gè)任務(wù)耗時(shí)過(guò)長(zhǎng)后面的任務(wù)全部被拖慢。這個(gè)特性在響應(yīng)性要求高的業(yè)務(wù)里是災(zāi)難。第二TimerTask拋出的異常會(huì)直接終結(jié)整個(gè)Timer。一個(gè)任務(wù)掛了其他所有任務(wù)跟著遭殃而且沒(méi)有任何日志提示排查起來(lái)特別懵。還有一個(gè)行為細(xì)節(jié)值得注意Timer.schedule()和Timer.scheduleAtFixedRate()對(duì)“錯(cuò)過(guò)執(zhí)行時(shí)間”的處理不同。前者按相對(duì)間隔推遲執(zhí)行后者會(huì)試圖補(bǔ)上落下的執(zhí)行次數(shù)在系統(tǒng)繁忙時(shí)可能造成任務(wù)瞬間爆發(fā)。這倆差異不仔細(xì)看文檔的話很容易在壓測(cè)環(huán)境里暴雷。5.2 用ScheduledExecutorService替代Timer線程池出現(xiàn)之后Timer基本成了歷史包袱。ScheduledExecutorService從語(yǔ)義上更清晰它底層是線程池多個(gè)任務(wù)之間天然隔離單個(gè)任務(wù)異常穿透時(shí)只影響那個(gè)任務(wù)自身不會(huì)拖垮整個(gè)調(diào)度器。日常寫(xiě)定時(shí)任務(wù)我首選這個(gè)方案。import java.util.concurrent.Executors; import java.util.concurrent.ScheduledExecutorService; import java.util.concurrent.TimeUnit; public class SchedulerDemo { public static void main(String[] args) { ScheduledExecutorService scheduler Executors.newScheduledThreadPool(1); scheduler.scheduleWithFixedDelay(() - { System.out.println(心跳任務(wù)執(zhí)行 System.currentTimeMillis()); }, 1, 2, TimeUnit.SECONDS); // 模擬十分鐘后關(guān)閉 scheduler.schedule(() - { System.out.println(調(diào)度器關(guān)閉); scheduler.shutdown(); }, 10, TimeUnit.MINUTES); } }寫(xiě)業(yè)務(wù)代碼時(shí)我一般這樣區(qū)分兩個(gè)方法方法行為適用場(chǎng)景scheduleAtFixedRate以上一次任務(wù)開(kāi)始時(shí)間為基準(zhǔn)固定頻率觸發(fā)不關(guān)注任務(wù)實(shí)際耗時(shí)盡量少用容易造成任務(wù)重疊執(zhí)行scheduleWithFixedDelay以上一次任務(wù)結(jié)束時(shí)間為基準(zhǔn)固定延遲間隔觸發(fā)默認(rèn)推薦避免任務(wù)堆疊行為更好預(yù)判選scheduleWithFixedDelay的理由很直接現(xiàn)實(shí)中的任務(wù)耗時(shí)往往有抖動(dòng)如果你用固定頻率觸發(fā)一旦任務(wù)執(zhí)行時(shí)間超過(guò)預(yù)設(shè)周期下一個(gè)任務(wù)就會(huì)緊跟而來(lái)很快可以看到線程池被打滿。而固定延遲模式保證任務(wù)之間永遠(yuǎn)有緩沖間隔對(duì)系統(tǒng)更友好。5.3 任務(wù)執(zhí)行時(shí)間超過(guò)間隔怎么辦這是一個(gè)特別容易被忽略的工程問(wèn)題。假設(shè)你注冊(cè)了一個(gè)周期10秒的任務(wù)但任務(wù)內(nèi)部某次請(qǐng)求卡了30秒等到它返回時(shí)scheduleAtFixedRate會(huì)立刻補(bǔ)跑之前落下的執(zhí)行。如果補(bǔ)跑的任務(wù)本身也卡系統(tǒng)很快進(jìn)入“瘋狂重試”的惡性循環(huán)。所以我會(huì)在真實(shí)項(xiàng)目里做兩層保護(hù)調(diào)度層用scheduleWithFixedDelay從根上避免密集補(bǔ)跑。任務(wù)內(nèi)部再做一層超時(shí)控制比如用CompletableFuture加get(timeout)兜底防止任務(wù)自身長(zhǎng)時(shí)間霸占線程。另外如果你的任務(wù)既重又頻繁建議把“需要長(zhǎng)時(shí)間執(zhí)行的工作”丟到一個(gè)獨(dú)立的業(yè)務(wù)線程池調(diào)度線程只負(fù)責(zé)任務(wù)編排。否則一條調(diào)度線程池再智能也算不清它拖了多少后續(xù)任務(wù)的啟動(dòng)時(shí)間。6. 計(jì)時(shí)器落地的典型業(yè)務(wù)場(chǎng)景與精度陷阱6.1 三個(gè)真實(shí)業(yè)務(wù)中離不開(kāi)計(jì)時(shí)器的場(chǎng)景很多同學(xué)學(xué)完線程不知道多線程到底可以用在哪。計(jì)時(shí)器這個(gè)形態(tài)其實(shí)滲透得很廣。第一個(gè)是接口耗時(shí)監(jiān)控。寫(xiě)一個(gè)切面記錄方法調(diào)用前的nanoTime方法執(zhí)行完再算一次差值超過(guò)閾值就告警。這里“計(jì)時(shí)器”就是一段計(jì)算耗時(shí)邏輯不需要獨(dú)立線程但要把測(cè)量起點(diǎn)和終點(diǎn)包得足夠可靠。第二個(gè)是心跳與?；?。后臺(tái)調(diào)度線程每N秒向服務(wù)端發(fā)送一個(gè)心跳包或者檢查某個(gè)連接是否還在這本質(zhì)上就是scheduleWithFixedDelay的業(yè)務(wù)化身。第三個(gè)是定期刷新緩存。常見(jiàn)的“本地緩存五秒刷新一次”就是一個(gè)典型的定時(shí)任務(wù)。這類場(chǎng)景不需要自己做線程協(xié)作重點(diǎn)是選對(duì)調(diào)度工具并且保證任務(wù)內(nèi)部異常不泄漏。6.2 用nanoTime測(cè)耗時(shí)不要拿currentTimeMillis硬算要在計(jì)時(shí)器項(xiàng)目里養(yǎng)成一個(gè)好習(xí)慣測(cè)量時(shí)間間隔用System.nanoTime()不要用System.currentTimeMillis()。原因很微妙currentTimeMillis返回的是“墻上時(shí)鐘時(shí)間”它可能因?yàn)橄到y(tǒng)對(duì)時(shí)、用戶改時(shí)間、NTP同步而前后跳變。如果剛好在改時(shí)間的那一秒做耗時(shí)統(tǒng)計(jì)計(jì)算出來(lái)的耗時(shí)可能是負(fù)數(shù)或者瞬間暴漲到幾小時(shí)。而nanoTime是單調(diào)遞增的計(jì)時(shí)器專門(mén)用來(lái)測(cè)量時(shí)間差不受系統(tǒng)時(shí)間調(diào)整影響。long start System.nanoTime(); // 執(zhí)行需要監(jiān)控的業(yè)務(wù)邏輯 long costNs System.nanoTime() - start; long costMs TimeUnit.NANOSECONDS.toMillis(costNs); System.out.println(接口耗時(shí): costMs ms);注意nanoTime雖然精度高但它沒(méi)有絕對(duì)時(shí)間語(yǔ)義不能用來(lái)?yè)Q算成某年某月某日只適合算差值。6.3 超時(shí)控制的經(jīng)典姿勢(shì)Future get(timeout)有種“計(jì)時(shí)器”不用自己數(shù)秒而是讓框架幫你等發(fā)一個(gè)異步任務(wù)出去限制它多少毫秒內(nèi)必須返回超時(shí)就按失敗處理。這種模式在RPC調(diào)用、數(shù)據(jù)庫(kù)查詢、外部API請(qǐng)求里特別常見(jiàn)。import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.Future; import java.util.concurrent.TimeUnit; import java.util.concurrent.TimeoutException; public class TimeoutDemo { public static void main(String[] args) throws Exception { ExecutorService pool Executors.newFixedThreadPool(2); FutureString future pool.submit(() - { Thread.sleep(5000); return 任務(wù)結(jié)果; }); try { String result future.get(2, TimeUnit.SECONDS); System.out.println(拿到結(jié)果: result); } catch (TimeoutException e) { System.out.println(任務(wù)超時(shí)做降級(jí)處理); future.cancel(true); } finally { pool.shutdown(); } } }future.get(timeout)是并發(fā)編程里最實(shí)用的“鬧鐘”之一。它幫你自動(dòng)完成“計(jì)時(shí)檢查異常處理”的閉環(huán)不需要你手動(dòng)維護(hù)秒數(shù)變量。我個(gè)人的使用偏好是凡是讓外部資源干活的地方都加一層超時(shí)控制寧可快速失敗也別讓請(qǐng)求服務(wù)無(wú)限期掛起。7. 多線程計(jì)時(shí)器調(diào)試經(jīng)驗(yàn)與常見(jiàn)問(wèn)題速查7.1 排查計(jì)時(shí)器問(wèn)題時(shí)的日志套路多線程程序調(diào)試最難的是信息不對(duì)稱你根本看不到哪個(gè)線程在哪一步停住了。我自己的做法是在三個(gè)關(guān)鍵節(jié)點(diǎn)打日志狀態(tài)變更、循環(huán)開(kāi)始、循環(huán)結(jié)束。比如pause()方法一被調(diào)用立刻記錄“paused 置為 true當(dāng)前剩余秒數(shù)xxx”resume()被調(diào)用記錄“paused 置為 false已發(fā)出 notifyAll”。這樣一旦行為不對(duì)回看日志就能還原出時(shí)間線。日志格式上建議帶上線程名和時(shí)間戳不要只打一句話。像上面代碼里我給workerThread起的名字是countdown-worker真到線上排查時(shí)main、pool-1-thread-1這種默認(rèn)名字會(huì)讓你對(duì)人不對(duì)事。日志里把線程名帶出來(lái)配合jstack抓線程快照基本能一眼定位是哪個(gè)環(huán)節(jié)卡住。7.2 常見(jiàn)問(wèn)題速查表現(xiàn)象常見(jiàn)根因處理方式計(jì)時(shí)線程永遠(yuǎn)停不下來(lái)catch InterruptedException后沒(méi)有補(bǔ)回中斷標(biāo)志位或線程在阻塞中無(wú)法響應(yīng)volatile標(biāo)志在catch塊里調(diào)用Thread.currentThread().interrupt()并考慮主動(dòng)return界面假死、按鈕無(wú)響應(yīng)在GUI事件線程里直接sleep或死循環(huán)阻塞把計(jì)時(shí)任務(wù)放到獨(dú)立線程或線程池絕不在事件派發(fā)線程里阻塞暫停之后無(wú)法恢復(fù)只改了暫停標(biāo)志位沒(méi)有調(diào)用notifyAll()喚醒wait()的線程在resume()和stop()中都同步喚醒阻塞線程一個(gè)定時(shí)任務(wù)出錯(cuò)所有任務(wù)都不執(zhí)行了使用Timer且任務(wù)內(nèi)部沒(méi)有異常兜底改用ScheduledExecutorService任務(wù)內(nèi)部catch所有Exception這張表是我做計(jì)時(shí)器案例時(shí)踩坑記錄的濃縮版。前兩類最容易出現(xiàn)在學(xué)習(xí)階段后兩類基本只有寫(xiě)真實(shí)業(yè)務(wù)才會(huì)遇到。每次排查完順手把現(xiàn)象整理成這種格式攢上十幾條你對(duì)多線程的理解會(huì)比讀十篇博客都扎實(shí)。7.3 一個(gè)擴(kuò)展玩法計(jì)時(shí)結(jié)束之后自動(dòng)回調(diào)基礎(chǔ)版計(jì)時(shí)器只能在控制臺(tái)打印真實(shí)項(xiàng)目里往往需要“倒計(jì)時(shí)結(jié)束之后自動(dòng)執(zhí)行某件事”比如跳轉(zhuǎn)頁(yè)面、發(fā)送通知、觸發(fā)一個(gè)異步流程。這個(gè)需求可以用CompletableFuture優(yōu)雅地完成不需要重新造輪子。import java.util.concurrent.CompletableFuture; import java.util.concurrent.TimeUnit; public class CountdownCallback { public static void main(String[] args) { CompletableFutureVoid countdown CompletableFuture.runAsync(() - { for (int i 5; i 0; i--) { System.out.println(倒計(jì)時(shí): i); try { Thread.sleep(1000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } } }); countdown.thenRun(() - System.out.println(倒計(jì)時(shí)結(jié)束執(zhí)行回調(diào))); // 主線程干點(diǎn)別的 System.out.println(主線程繼續(xù)執(zhí)行其他邏輯); } }runAsync把倒計(jì)時(shí)過(guò)程放到公共線程池thenRun注冊(cè)一個(gè)回調(diào)倒計(jì)時(shí)結(jié)束自動(dòng)觸發(fā)。組合式寫(xiě)法比手動(dòng)維護(hù)“計(jì)時(shí)線程結(jié)束后去調(diào)哪個(gè)方法”清爽得多。這也是我目前處理“定時(shí)后處理”最常用的結(jié)構(gòu)代碼簡(jiǎn)單可讀性強(qiáng)后續(xù)擴(kuò)展多個(gè)連續(xù)動(dòng)作也方便。我個(gè)人在實(shí)際操作中的體會(huì)是計(jì)時(shí)器看似簡(jiǎn)單但它把并發(fā)編程里最容易翻車(chē)的幾個(gè)點(diǎn)集中放大了。你能把一個(gè)計(jì)時(shí)器從“while循環(huán)能跑”一步一步改成“可控、可停、可恢復(fù)、可回調(diào)”說(shuō)明你對(duì)線程模型、共享狀態(tài)、調(diào)度策略已經(jīng)建立了直覺(jué)。學(xué)到這里的同學(xué)建議自己動(dòng)手補(bǔ)齊一個(gè)功能在倒計(jì)時(shí)結(jié)束前5秒讓控制臺(tái)輸出一次警告順便處理掉main線程直接退出導(dǎo)致的計(jì)時(shí)器中斷問(wèn)題。這個(gè)擴(kuò)展不大但能把本文提到的大部分知識(shí)點(diǎn)再完整走一遍比收藏三遍博文有用得多。希望這篇能成為你深挖并發(fā)編程的起點(diǎn)而不是終點(diǎn)。