你們有沒有過這種時(shí)刻線上服務(wù)突然卡死日志瘋狂刷屏你盯著監(jiān)控面板大腦一片空白旁邊的同事已經(jīng)開始重啟大法了。你硬著頭皮打開線程 dump看到一堆堆棧信息忽然腦子里蹦出一個(gè)詞——死鎖然后再往下想兩個(gè)線程互相持有對方需要的鎖經(jīng)典面試題里的場景就這么水靈靈地出現(xiàn)在了你面前。那一刻我承認(rèn)我是有點(diǎn)恍惚的。以前刷了不知道多少遍的八股文什么 synchronized 和 ReentrantLock 的區(qū)別什么鎖升級、鎖消除、CAS 原理當(dāng)時(shí)只覺得是“面試造火箭工作擰螺絲”的典型代表。可當(dāng)那個(gè)問題真的出現(xiàn)時(shí)能救你的恰恰就是這些被你鄙視過無數(shù)次的“死知識(shí)”。所以今天想認(rèn)真聊聊這個(gè)反直覺的話題八股文到底能不能解決實(shí)際問題如果能它解決的到底是什么層面的問題更重要的是你怎么背才能在關(guān)鍵時(shí)刻用它把問題摁死而不是只會(huì)寫“講一下 volatile 的可見性原理”這種標(biāo)準(zhǔn)答案。1. 八股文被吐槽的根源從一次線上事故說起先講一個(gè)我自己的經(jīng)歷應(yīng)該很多人都遇到過類似的場景。有一年我們做一個(gè)偏底層的服務(wù)核心邏輯是接收上游的消息處理和轉(zhuǎn)發(fā)對延遲要求極其敏感。本來跑得好好的結(jié)果某次發(fā)版后開始隔三差五出現(xiàn)局部超時(shí)。剛開始大家以為是網(wǎng)絡(luò)抖動(dòng)或者上游服務(wù)不穩(wěn)定的鍋畢竟這種分布式環(huán)境里甩鍋給網(wǎng)絡(luò)是最高效的止損方式。但連續(xù)幾天都超時(shí)而且是很有規(guī)律的幾分鐘一次這就不能繼續(xù)裝看不見了。我一邊看著監(jiān)控一邊查日志發(fā)現(xiàn)出問題的時(shí)間點(diǎn)CPU 使用率并不高內(nèi)存也很穩(wěn)定GC 也正常但就是有大量請求卡在某個(gè)節(jié)點(diǎn)上遲遲不返回。當(dāng)時(shí)我就想到了線程死鎖。可是很奇怪代碼是從老項(xiàng)目里遷移過來的鎖用的都是挺保守的 synchronized按理說不容易出現(xiàn)這種交叉持鎖。我拉了一份線程 dump用命令把 jstack 的輸出存下來然后去數(shù)那些停留在 BLOCKED 狀態(tài)的線程。結(jié)果確實(shí)有線程互相等待但問題沒我想的那么簡單。我再仔細(xì)看代碼發(fā)現(xiàn)不光是 synchronized還有一個(gè) ReentrantLock.tryLock() 的使用它里面帶了一個(gè)超時(shí)時(shí)間按理說就算拿不到鎖也應(yīng)該超時(shí)返回不至于死死卡住。但這里有一個(gè)非常隱蔽的坑tryLock 超時(shí)后代碼走的是失敗分支而失敗分支里它會(huì)再次嘗試獲取另一個(gè)鎖。結(jié)果就是A 線程先拿到鎖1再去 tryLock 鎖2超時(shí)了回頭釋放鎖1B 線程同時(shí)拿到鎖2再去拿鎖1也超時(shí)了然后釋放鎖2再去 tryLock 鎖1……兩個(gè)線程就這樣互相謙讓永遠(yuǎn)拿不到對方手里的鎖但又不進(jìn)入 BLOCKED 狀態(tài)因?yàn)?tryLock 的超時(shí)讓線程一直在“活躍地等待”。這種情況在監(jiān)控上看非常具有迷惑性——線程沒有死鎖因?yàn)榫€程狀態(tài)是 WAITING 或 RUNNABLE而不是 BLOCKEDCPU 又不高因?yàn)榇蟛糠謺r(shí)間是在 sleep請求超時(shí)卻一直在發(fā)生。排查了很久最后是一個(gè)老同事提了一嘴你是不是沒學(xué)過“活鎖”你要是跟面試一樣只看死鎖那幾種模板肯定栽這。那一瞬間我是真的被擊中了。面試我背過活鎖和死鎖的區(qū)別背的時(shí)候覺得這有什么好考的誰沒事寫一個(gè)活鎖出來。可現(xiàn)實(shí)就是活鎖不僅真的會(huì)出現(xiàn)還比死鎖更難排查因?yàn)樗挥|發(fā)常規(guī)死鎖檢測機(jī)制。后來我們修復(fù)的方式也很樸素把鎖的獲取順序全局統(tǒng)一然后盡量縮小鎖粒度再給整個(gè)操作加了一個(gè)頂層的超時(shí)熔斷讓卡死的調(diào)用鏈直接失敗返回而不是無限重試。這段經(jīng)歷讓我徹底改變了學(xué)八股文的姿勢單純背概念當(dāng)然沒用但如果你知道這個(gè)概念對應(yīng)的真實(shí)故障場景你就會(huì)在排查時(shí)多一條路可走多一個(gè)參數(shù)可查。同樣的道理很多八股文知識(shí)點(diǎn)垃圾回收算法、JMM 內(nèi)存模型、HashMap 擴(kuò)容機(jī)制、線程池拒絕策略看似只是面試題其實(shí)背后都對應(yīng)著一類非常具體的線上問題。關(guān)鍵的區(qū)別在于你背的是結(jié)論還是背的場景和觸發(fā)條件。2. 那些被忽視的“死知識(shí)”為何在關(guān)鍵時(shí)刻救命我們得先搞清楚一個(gè)前提為啥我們會(huì)覺得八股文沒用。因?yàn)榻^大多數(shù)時(shí)候開發(fā)工作確實(shí)是體力活寫接口、聯(lián)調(diào)、CRUD、改 bug、發(fā)版這些事確實(shí)不需要你懂 JVM 內(nèi)存屏障也不需要你知道 B 樹為什么是三層結(jié)構(gòu)。但“正常運(yùn)行的時(shí)候”和“出事的時(shí)候”對知識(shí)儲(chǔ)備的要求完全是兩碼事。平時(shí)是開發(fā)模式出了問題就是排查模式而排查模式拼的恰恰是你對系統(tǒng)底層機(jī)制的理解深度。打個(gè)比方你開車上下班每天走的都是同一條路路況好、天氣好你不需要懂發(fā)動(dòng)機(jī)原理只需要會(huì)踩油門剎車就行。但有一天車子在高速上開始異響儀表盤亮了一盞黃燈你停還是不?？窟呥€是不靠邊繼續(xù)開會(huì)怎樣這個(gè)時(shí)候懂一點(diǎn)發(fā)動(dòng)機(jī)、變速箱、供油系統(tǒng)的基本原理和完全不懂面對同樣的情況處理方式是完全不同的。八股文的作用就在于它能幫你在“只看到表象”的時(shí)候快速定位到“可能的底層原因”。它有這個(gè)功能是因?yàn)榘斯晌募辛四闼陬I(lǐng)域的核心機(jī)制、核心數(shù)據(jù)結(jié)構(gòu)、核心算法的精華它們不是憑空捏造的面試題而是一個(gè)系統(tǒng)之所以能夠穩(wěn)定運(yùn)行的底層邏輯。我自己用下來感觸最深的一個(gè)例子是 HashMap。很多人的八股文記憶是HashMap 的底層是數(shù)組加鏈表JDK 1.8 之后加了紅黑樹默認(rèn)容量是 16負(fù)載因子是 0.75擴(kuò)容是變成原來的兩倍。說實(shí)話我剛背的時(shí)候也覺得這是面試官閑著沒事干這玩意兒跟我寫代碼有什么關(guān)系直到后來出過一次線程安全問題。那次事故的現(xiàn)場是這樣的我們一個(gè)接口平時(shí)響應(yīng)很快某天開始出現(xiàn)周期性抖動(dòng)單看接口本身沒有明顯瓶頸數(shù)據(jù)庫也查過了慢日志也沒有。后來查到一個(gè)靜態(tài)工具類里有一個(gè) ConcurrentHashMap代碼邏輯是先從 Map 里取一個(gè)配置取不到就去數(shù)據(jù)庫加載加載完再 put 進(jìn)去。這個(gè)代碼在并發(fā)量很低的時(shí)段沒問題但一旦流量上來多個(gè)線程同時(shí)發(fā)現(xiàn)配置缺失同時(shí)去數(shù)據(jù)庫加載再同時(shí)執(zhí)行 put就會(huì)出現(xiàn)大量阻塞和重復(fù)加載。排查的過程中我下意識(shí)地想到了 ConcurrentHashMap 的鎖分段機(jī)制想到了 JDK 1.8 里用 CAS synchronized 只鎖桶首節(jié)點(diǎn)想到了 computeIfAbsent 這個(gè)方法其實(shí)在并發(fā)場景下也可能觸發(fā)多次計(jì)算。如果沒有這些八股文打底我可能只能看到表象接口變慢了負(fù)載上去了至于為什么變慢為什么要優(yōu)化這里的代碼根本無從下手。還有一次是關(guān)于線程池的。一個(gè)微服務(wù)在高峰期莫名 OOM查內(nèi)存 dump 發(fā)現(xiàn)隊(duì)列里堆了大量任務(wù)。當(dāng)時(shí)他們用的線程池配置是核心線程 10最大線程 50隊(duì)列容量是 Integer.MAX_VALUE。這個(gè)配置放在面試題里答案很簡單隊(duì)列無限大最大線程數(shù)永遠(yuǎn)沒意義任務(wù)都堆在隊(duì)列里內(nèi)存遲早爆掉?？涩F(xiàn)實(shí)中很多人就是圖簡單以為隊(duì)列設(shè)大一點(diǎn)就能提升吞吐量結(jié)果就是請求全部積壓系統(tǒng)徹底被拖垮。所以你看八股文并不“只是”為了面試它其實(shí)是行業(yè)內(nèi)無數(shù)經(jīng)驗(yàn)教訓(xùn)濃縮出來的checklist。它把那些最容易出問題的邊界情況、最容易踩的坑、最容易被忽略的底層機(jī)制整理成了一個(gè)個(gè)短小精悍的問題逼著你提前去理解而不是等線上炸了再去查資料。3. 真正解決實(shí)戰(zhàn)問題的“八股時(shí)刻表”按場景對號入座話雖這么說也不能把所有八股文都一股腦當(dāng)成葵花寶典來練。不同的知識(shí)對應(yīng)的是不同的問題場景。我根據(jù)自己的實(shí)戰(zhàn)經(jīng)驗(yàn)把常見的八股文知識(shí)做了一下歸類方便你在慘烈的事件現(xiàn)場快速對號入座。第一類基礎(chǔ)底層原理類。比如 JMM、volatile、synchronized、CAS、AQS、鎖升級。這類知識(shí)的價(jià)值主要在線程安全問題的排查上典型癥狀是數(shù)據(jù)不一致、偶發(fā)性的臟讀、并發(fā)環(huán)境下統(tǒng)計(jì)結(jié)果不準(zhǔn)、死鎖與活鎖、CPU 飆高但線程 dump 又看不出明顯的死鎖等。排查時(shí)有這些知識(shí)打底你會(huì)發(fā)現(xiàn)你看線程 dump、看堆棧信息、看 JVM 參數(shù)的時(shí)候根本不需要臨時(shí)抱佛腳大概瞄一眼就能鎖定方向。第二類集合與數(shù)據(jù)結(jié)構(gòu)類。HashMap、ConcurrentHashMap、ArrayList、LinkedList 的底層實(shí)現(xiàn)和擴(kuò)容機(jī)制你可能會(huì)說這有什么好聊的但恰恰是這類基礎(chǔ)的東西最容易出現(xiàn)問題因?yàn)樗鼈兲Ｓ昧舜蠹姨焯煊脜s幾乎不關(guān)心它的邊界行為。典型場景包括并發(fā)擴(kuò)容導(dǎo)致 CPU 100%、HashMap 死循環(huán)、ArrayList 迭代過程中 remove 導(dǎo)致 ConcurrentModificationException、subList 視圖不更新、Collections.unmodifiableList 只做了淺層不可變等。不要覺得這些都是“老掉牙的坑”我身邊確實(shí)有人把 ArrayList 從一個(gè)線程往另一個(gè)線程傳結(jié)果遍歷的時(shí)候報(bào)錯(cuò)查了半天不知道什么情況。第三類JVM 與內(nèi)存管理類。特別是垃圾回收機(jī)制、對象分配、內(nèi)存屏障、類加載機(jī)制。這類知識(shí)在 OOM、Full GC 頻繁、JVM 參數(shù)調(diào)優(yōu)、定位對象泄漏時(shí)非常好用。比如我以前遇到過一個(gè)問題接口響應(yīng)變慢排查的時(shí)候 CPU 不高、線程也不阻塞但 GC 日志顯示 Young GC 非常頻繁且耗時(shí)很長。如果沒有 GC 知識(shí)你根本不知道該去看 GC 日志也看不懂為什么 Epsilon 垃圾回收器不適合生產(chǎn)環(huán)境更不要提根據(jù)對象分配速率去定位是在哪一行代碼頻繁創(chuàng)建大對象了。第四類并發(fā)工具類與框架原理類。比如線程池參數(shù)、BlockingQueue 的公平與不公平特性、CountDownLatch/CyclicBarrier/Semaphore 的設(shè)計(jì)初衷、CompletableFuture 的異步回調(diào)機(jī)制、Spring 的循環(huán)依賴與三級緩存。這類知識(shí)在復(fù)雜的業(yè)務(wù)代碼里最容易救命。遇到業(yè)務(wù)里一個(gè)接口同時(shí)調(diào)多個(gè)下游需要并發(fā)等待匯總你如果不知道 CompletableFuture 的這些邊界行為就會(huì)拼命 new Thread 然后 join代碼又丑又容易出 bug。第五類網(wǎng)絡(luò)與數(shù)據(jù)庫類。TCP 三次握手四次揮手、TIME_WAIT 和 CLOSE_WAIT、索引為什么用 B 樹、索引失效的常見場景、事務(wù)隔離級別、MVCC、間隙鎖。這類八股文的應(yīng)用場景幾乎是最高頻的。尤其是數(shù)據(jù)庫相關(guān)的線上慢查詢排查、死鎖日志分析、數(shù)據(jù)庫連接池被打滿、事務(wù)超時(shí)哪一樣不需要 MVCC 和索引原理打底你去看一個(gè)執(zhí)行計(jì)劃如果不懂索引最左前綴匹配是怎么回事你連解釋執(zhí)行計(jì)劃的勇氣都沒有。我把這些常用知識(shí)用一張表整理出來雖然沒辦法覆蓋所有場景但你可以把它當(dāng)作現(xiàn)場排查時(shí)的索引目錄按圖索驥效率會(huì)高很多。八股文知識(shí)點(diǎn)對應(yīng)的典型線上問題排查時(shí)的切入點(diǎn)JMM、volatile、CAS、AQS數(shù)據(jù)不一致、偶發(fā)臟讀、并發(fā)統(tǒng)計(jì)錯(cuò)誤線程 dump、內(nèi)存可見性分析、鎖競爭監(jiān)控HashMap/ConcurrentHashMap 底層并發(fā)擴(kuò)容、CPU 100%、數(shù)據(jù)丟失擴(kuò)容閾值分析、鎖粒度分析、Map 遍歷方式垃圾回收與對象分配Full GC 頻繁、OOM、響應(yīng)抖動(dòng)GC 日志、堆 dump、對象分配速率線程池參數(shù)與拒絕策略任務(wù)排隊(duì)堆積、內(nèi)存暴漲、核心業(yè)務(wù)不可用隊(duì)列積壓長度、線程池監(jiān)控參數(shù)數(shù)據(jù)庫索引與事務(wù)隔離慢查詢、死鎖、幻讀、數(shù)據(jù)不一致執(zhí)行計(jì)劃、鎖等待日志、隔離級別配置這套“八股時(shí)刻表”最大的價(jià)值不是讓你照抄而是提醒你這些知識(shí)不是孤立的面試知識(shí)點(diǎn)而是一張張“故障地圖”。你真正需要做的是像背地圖一樣把它們和實(shí)際故障場景關(guān)聯(lián)起來。遇到異常時(shí)你的第一反應(yīng)不應(yīng)該是慌張而是在那張圖里找到對應(yīng)的可能原因再逐步驗(yàn)證。4. 從“背八股”到“用八股”一個(gè)資深工程師的復(fù)盤方法那么問題就來了到底怎么背才能在關(guān)鍵時(shí)刻輸出真正的“戰(zhàn)斗力”我自己走過幾個(gè)階段也踩過不少彎路。最初的階段就是純背題看過很多面試經(jīng)驗(yàn)帖把高頻題的問題和答案整理在一個(gè)文檔里。背的時(shí)候朗朗上口什么“解決哈希沖突的兩種常見方法拉鏈法和開放地址法”“ConcurrentHashMap 為什么是線程安全的”。但實(shí)際工作里這些句子一句都用不上——因?yàn)樗鼈兪墙Y(jié)論不是推理過程。后來我換了一個(gè)方法不再背“標(biāo)準(zhǔn)答案”而是背“問題鏈”。什么意思就是把一道題拆成幾個(gè)遞進(jìn)的問題從“是什么”一直問到“為什么是這樣設(shè)計(jì)的”和“如果改掉會(huì)怎樣”一步一步建立因果鏈條。舉個(gè)例子就拿“HashMap 線程不安全”來說我現(xiàn)在的腦子里不是一個(gè)孤立結(jié)論而是一條完整的因果鏈為什么線程不安全因?yàn)槎嗑€程同時(shí) put 時(shí)可能觸發(fā)擴(kuò)容多個(gè)線程同時(shí) rehash導(dǎo)致桶數(shù)組的鏈表形成環(huán)下次 get 的時(shí)候進(jìn)入死循環(huán)為什么會(huì)形成環(huán)因?yàn)榕f鏈表采用頭插法并發(fā)擴(kuò)容時(shí)兩個(gè)線程同時(shí)遍歷舊鏈表互相修改 next 引用導(dǎo)致鏈表出現(xiàn)循環(huán)那 JDK 1.8 改成尾插法之后線程安全了嗎不完全安全雖然不會(huì)再有死循環(huán)但并發(fā) put 時(shí)可能出現(xiàn)數(shù)據(jù)覆蓋丟失size 統(tǒng)計(jì)也不準(zhǔn)確那什么場景下能保證安全單線程、或者用 Collections.synchronizedMap 包裹再或者直接用 ConcurrentHashMap。這一串問題鏈背下來你對 HashMap 的理解就完全不是“背了個(gè)答案”的層次了。你遇到任何相關(guān)的并發(fā)問題都能順著這條鏈去推理。比如線上出現(xiàn)了 HashMap 死循環(huán)導(dǎo)致 CPU 100%你不需要百度腦子里就已經(jīng)有一個(gè)大致的排查方向——先看是不是并發(fā)環(huán)境下的擴(kuò)容再看是不是 JDK 8 之前的版本。那排起錯(cuò)來思路是完全不一樣的。除了在方法論上做調(diào)整還有一個(gè)很大的心得是要主動(dòng)把八股文和業(yè)務(wù)代碼做映射。什么意思呢寫代碼的時(shí)候不要只想著“我實(shí)現(xiàn)這個(gè)功能”也要順手問問自己這個(gè)接口會(huì)被并發(fā)調(diào)用嗎我用的這個(gè)集合類線程安全嗎如果 QPS 突然漲到十倍我這個(gè)線程池配置會(huì)不會(huì)成為瓶頸這個(gè)循環(huán)里我是不是在頻繁創(chuàng)建對象會(huì)不會(huì)導(dǎo)致 GC 壓力過大這個(gè) SQL 的 where 條件能不能走索引能不能優(yōu)化這些問題表面上看是在“給自己加戲”實(shí)際上是在倒逼你把八股文里的知識(shí)真正融合到日常開發(fā)習(xí)慣里。等你做過幾次這種映射之后你會(huì)慢慢發(fā)現(xiàn)背過的知識(shí)點(diǎn)不再是文檔里的文字而是變成了你寫代碼時(shí)的一種直覺一看就知道哪里會(huì)炸哪里要提前做防護(hù)。再分享一個(gè)我自己比較受用的復(fù)盤方法——出故障之后做“事故映射復(fù)盤”。每次線上故障處理完之后我會(huì)專門花一段時(shí)間把故障過程中用到的所有底層知識(shí)點(diǎn)單獨(dú)拎出來對照著一個(gè)“問題清單”去復(fù)盤包括這次遇到的故障最核心的技術(shù)機(jī)制是什么我在排查過程中哪些知識(shí)是靠積累直接想到的哪些知識(shí)是臨時(shí)翻資料才想起來的如果下次再遇到類似問題有沒有更快定位的切入點(diǎn)這個(gè)問題是否可以抽象成一個(gè)可以復(fù)用的 FAQ寫進(jìn)團(tuán)隊(duì)知識(shí)庫這個(gè)方法堅(jiān)持下來最大的變化是你的八股文知識(shí)會(huì)變得越來越“場景化”。以前背過的“線程池的核心線程數(shù)如何設(shè)置”這種題你可能只是記了一個(gè)公式但當(dāng)你經(jīng)歷過一次由于隊(duì)列隊(duì)列大隊(duì)列容量設(shè)置不合理導(dǎo)致的 OOM 之后你會(huì)徹底記住線程池的參數(shù)權(quán)衡關(guān)系而且是帶著強(qiáng)烈的實(shí)戰(zhàn)印象去記住的這種記憶是刷一百道面試題都比不上的。關(guān)于閱讀源碼我也想多說一句。很多人提到源碼就頭大覺得這東西離自己太遠(yuǎn)。但實(shí)際上不用非得通讀整個(gè) JDK 源碼只需要在你用到一個(gè)類的時(shí)候去翻看和你關(guān)系最大的那幾段源碼就夠了。比如你用 ConcurrentHashMap 的時(shí)候去看看它的 spread 方法和 putVal 方法你用 ThreadPoolExecutor 的時(shí)候去看看 execute 方法里線程池狀態(tài)流轉(zhuǎn)的幾個(gè)分支。這些源碼讀起來其實(shí)沒那么難但它能讓你徹底理解那些“八股答案”是怎么推導(dǎo)出來的真正變成你自己腦子里的東西。所以別再急著嘲笑八股文了。它確實(shí)不是萬能的但很多時(shí)候它能解決你 80% 的突發(fā)問題前提是你得把它從“死記硬背的面試題”變成“活學(xué)活用的底層知識(shí)體系”。怎么說呢面試的時(shí)候你能說出來那只能證明你記憶力不錯(cuò)但在線上事故現(xiàn)場你能憑它精準(zhǔn)定位問題那它才是真正屬于你的本事。