解析：集合、JVM、并發(fā)、MySQL與分布式)
每到二月底技術(shù)社群里問得最多的就不再是什么框架原理了而是一句“金三銀四沖大廠Java面試題現(xiàn)在該看什么”。我在面試官的位置上坐過也在候選人那一側(cè)被面過幾十輪給一個(gè)比較實(shí)在的結(jié)論大廠面試再怎么換風(fēng)格Java基礎(chǔ)、并發(fā)、JVM、Spring、數(shù)據(jù)存儲(chǔ)、分布式這六個(gè)板塊始終是繞不開的主線。這篇文章不搞那種幾百題的流水賬而是把我自己印象里出現(xiàn)頻率最高、也最容易翻車的幾類 Java 面試題連同面試官的追問邏輯和參考回答一起拆開講。按這條線往下過不敢說穩(wěn)過但至少不會(huì)踩空。1. Java基礎(chǔ)題看似簡單卻最容易翻車的考點(diǎn)1.1 從“”到equals再到hashCode一條線理清楚基礎(chǔ)題在大廠面試?yán)飶膩聿蝗毕芏嗳饲∏煸谧詈唵蔚念}目上。先看這個(gè)經(jīng)典問題“和equals有什么區(qū)別”如果作用于基本數(shù)據(jù)類型比較的是值本身如果作用于引用類型比較的是兩個(gè)引用是否指向同一個(gè)對象也就是內(nèi)存地址。而equals在沒有被重寫的情況下行為等同于但通常我們會(huì)重寫它來定義“邏輯相等”。比如兩個(gè)User對象只要身份證號(hào)相同就算同一個(gè)人這時(shí)候就應(yīng)該重寫equals而不是直接比較地址。面試官問完這一個(gè)十有八九會(huì)接一句“那equals和hashCode是什么關(guān)系”這里有個(gè)硬規(guī)矩重寫equals就必須重寫hashCode而且必須保證如果a.equals(b)為 true那么a.hashCode()必須等于b.hashCode()。原因其實(shí)很實(shí)際HashMap這類集合是靠hashCode定位桶再用equals去比較桶內(nèi)元素。如果你只重寫equals不重寫hashCode兩個(gè)邏輯上相等的 key 會(huì)落在不同的桶里HashMap就會(huì)存進(jìn)去兩份這顯然就破壞了 Map 的語義。順著這條線面試官還會(huì)繼續(xù)加碼“String 的equals和hashCode是怎么實(shí)現(xiàn)的String 的不變性有什么好處”String 類內(nèi)部用一個(gè)char數(shù)組或者byte數(shù)組存字符它的equals先比較引用、再比較長度、最后逐個(gè)字符比較。hashCode則是s[0]*31^(n-1) s[1]*31^(n-2) ...這種散列公式用 31 是因?yàn)樗且粋€(gè)奇質(zhì)數(shù)在乘法運(yùn)算里沖突概率相對低而且 JVM 對31 * i有優(yōu)化編譯器會(huì)把它轉(zhuǎn)成(i 5) - i位運(yùn)算比乘法快。String 的不變性讓它可以安全地被字符串常量池復(fù)用也保證了作為 HashMap 的 key 時(shí)哈希值不會(huì)變。這個(gè)問題的意義不在背答案而在考察你有沒有把“數(shù)據(jù)結(jié)構(gòu)”和“語言特性”聯(lián)系起來思考的習(xí)慣。1.2 HashMap 的底層結(jié)構(gòu)、擴(kuò)容機(jī)制與并發(fā)隱患HashMap 是 Java 面試?yán)锂?dāng)之無愧的“題王”。它的回答版本也在演進(jìn)JDK 7 及以前是數(shù)組加鏈表JDK 8 開始變成數(shù)組加鏈表加紅黑樹。默認(rèn)初始容量是 16負(fù)載因子是 0.75。什么意思就是當(dāng)元素個(gè)數(shù)超過16 * 0.75 12時(shí)會(huì)觸發(fā)擴(kuò)容容量翻倍到 32。為什么負(fù)載因子取 0.75 而不是 1 或者 0.5這是空間和時(shí)間的折中。負(fù)載因子越高空間利用率越高但哈希沖突概率變大鏈表長度增加查詢效率下降負(fù)載因子太低則空間浪費(fèi)太多。0.75 是官方在大量測試后給的經(jīng)驗(yàn)值。鏈表轉(zhuǎn)紅黑樹的閾值是 8樹轉(zhuǎn)回鏈表的閾值是 6之所以不是同一個(gè)數(shù)是為了避免元素在邊界來回浮動(dòng)時(shí)頻繁轉(zhuǎn)換。為什么閾值取 8本質(zhì)上是一個(gè)概率問題在隨機(jī)哈希函數(shù)下鏈表節(jié)點(diǎn)數(shù)服從泊松分布負(fù)載因子 0.75 時(shí)桶中鏈表長度達(dá)到 8 的概率已經(jīng)低于千萬分之一所以 8 是一個(gè)“幾乎不會(huì)出現(xiàn)但出現(xiàn)了就說明哈希分布極差”的信號(hào)。HashMap 的線程不安全是最常被追問的。JDK 7 里并發(fā) put 可能導(dǎo)致擴(kuò)容時(shí)鏈表形成環(huán)一旦 get 那個(gè) key 就會(huì)死循環(huán)CPU 直接飆滿。JDK 8 把頭插法改成了尾插法在一定程度上避免了環(huán)的產(chǎn)生但并發(fā)場景下依然有數(shù)據(jù)覆蓋問題兩個(gè)線程同時(shí)判斷某個(gè) key 不存在同時(shí)插入后寫覆蓋先寫還有一種情況是 put 過程中檢查到容量不夠多個(gè)線程同時(shí)擴(kuò)容導(dǎo)致數(shù)據(jù)丟失。所以并發(fā)場景不要用 HashMap要用ConcurrentHashMap。JDK 8 的 ConcurrentHashMap 放棄了 JDK 7 的分段鎖設(shè)計(jì)改為 CAS 加 synchronized 鎖住數(shù)組的單個(gè)槽位粒度更細(xì)并發(fā)度更高。我自己面試別人的時(shí)候通常會(huì)追問一句“為什么 JDK 8 要把擴(kuò)容后重新散列的算法改成高低位拆分”。JDK 7 擴(kuò)容是對每個(gè)元素重新計(jì)算 hash 再確定新位置JDK 8 優(yōu)化成根據(jù) hash 值新增的那一位是 0 還是 1元素要么留在原索引要么移動(dòng)到“原索引加舊容量”的位置。這樣做既省去了重新計(jì)算 hash 的開銷也減少了元素移動(dòng)次數(shù)。這個(gè)問題能答上來說明你確實(shí)讀過源碼而不是只看面經(jīng)。2. JVM 與內(nèi)存模型拉開差距的核心區(qū)2.1 運(yùn)行時(shí)數(shù)據(jù)區(qū)域與對象創(chuàng)建機(jī)制JVM 這塊可以說是大廠面試的分水嶺。背完“程序計(jì)數(shù)器、虛擬機(jī)棧、本地方法棧、堆、方法區(qū)”這五個(gè)名字只是入門關(guān)鍵是能講清楚每個(gè)區(qū)域里到底發(fā)生了什么。虛擬機(jī)棧管的是方法調(diào)用的過程。每次調(diào)用一個(gè)方法JVM 就會(huì)創(chuàng)建一個(gè)棧幀棧幀里有局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口。方法嵌套調(diào)用的深度是有上限的線程棧深度超過限制就會(huì)拋StackOverflowError。堆則是一切對象實(shí)例和數(shù)組的分配場所也是垃圾回收的主戰(zhàn)場。方法區(qū)在 JDK 8 里被移到了元空間不再使用虛擬機(jī)內(nèi)存而是用本地內(nèi)存這樣設(shè)計(jì)主要是為了避免永久代的OutOfMemoryError因?yàn)樵臻g默認(rèn)只受本機(jī)可用內(nèi)存限制并且字符串常量池在 JDK 7 時(shí)就已經(jīng)移到了堆里。對象的創(chuàng)建過程也經(jīng)常被連環(huán)追問類加載檢查、分配內(nèi)存、初始化零值、設(shè)置對象頭、執(zhí)行構(gòu)造方法。其中分配內(nèi)存那一步指針碰撞和空閑列表分別對應(yīng)“堆內(nèi)存規(guī)整”和“堆內(nèi)存不規(guī)整”兩種情況。如果是并發(fā)創(chuàng)建對象JVM 還需要解決線程安全問題主流做法是 CAS 加失敗重試或者使用線程本地分配緩沖TLAB。能聊到 TLAB 的候選人一般基礎(chǔ)就不會(huì)太差。2.2 垃圾回收算法與主流收集器垃圾回收問的是什么我認(rèn)為核心就兩個(gè)一是怎么判定對象已死二是怎么把垃圾高效清掉。判定對象已死主流答案是基于可達(dá)性分析。從 GC Roots 出發(fā)遍歷引用鏈不能被到達(dá)的對象就可以被回收。GC Roots 包括虛擬機(jī)棧中引用的對象、方法區(qū)中靜態(tài)屬性引用的對象、常量引用的對象、本地方法棧中 JNI 引用的對象等。這里有個(gè)經(jīng)典坑點(diǎn)兩個(gè)對象互相引用但都沒有被外部引用可達(dá)性分析依然能判定它們已死而引用計(jì)數(shù)法做不到所以現(xiàn)代主流的 JVM 都采用可達(dá)性分析。順帶一提面試官很可能繼續(xù)問“強(qiáng)引用、軟引用、弱引用、虛引用的區(qū)別”軟引用在內(nèi)存不足時(shí)會(huì)被回收弱引用在下一次 GC 時(shí)必被回收虛引用完全不影響生命周期只用于對象回收后的通知。回收算法里標(biāo)記-清除會(huì)產(chǎn)生大量碎片標(biāo)記-復(fù)制要浪費(fèi)一半空間標(biāo)記-整理要移動(dòng)對象?，F(xiàn)代的收集器基本都是分代設(shè)計(jì)新生代對象存活率低適合復(fù)制算法老年代對象存活率高適合標(biāo)記-整理或者標(biāo)記-清除。CMS 是第一款并發(fā)收集器它的初衷是減少停頓但犧牲了 CPU 資源并且會(huì)產(chǎn)生浮動(dòng)垃圾最后還因?yàn)闊o法處理碎片化問題在 JDK 9 里被標(biāo)記為廢棄。G1 把堆劃分成一個(gè)個(gè) Region可以做到可預(yù)測的停頓時(shí)間它的核心思路是維護(hù)一個(gè)優(yōu)先級(jí)列表回收價(jià)值最大的 Region 優(yōu)先。再往后就是 ZGC停頓時(shí)間控制在 10 毫秒以內(nèi)但越是新東西面試?yán)飭柕缴疃鹊母怕示驮降鸵驗(yàn)榇蠖鄶?shù)人沒有線上壓測經(jīng)驗(yàn)?zāi)艽鸪觥癎1 的 Region 結(jié)構(gòu)、Mixed GC、Remembered Set”已經(jīng)足夠過關(guān)。2.3 線上 OOM 排查的實(shí)戰(zhàn)套路大廠面試基本不滿足于讓你背概念經(jīng)常會(huì)把問題包裝成場景“線上突然 OOM你怎么處理”這類問題沒有唯一答案但有一套標(biāo)準(zhǔn)動(dòng)作。先看報(bào)錯(cuò)信息是Java heap space還是Metaspace還是Unable to create new native thread定位是哪塊區(qū)域出了問題。然后用jps找到進(jìn)程號(hào)jstat -gcutil看各代的使用率和 GC 頻率jmap -dump:formatb,fileheap.hprof導(dǎo)出堆快照再用 MAT 或者 JProfiler 分析。分析的時(shí)候先看支配樹找到占用內(nèi)存最大的那個(gè)對象再看引用鏈定位到業(yè)務(wù)代碼的哪一行。如果是內(nèi)存泄漏重點(diǎn)關(guān)注是否有全局緩存無限增長、數(shù)據(jù)庫連接關(guān)閉失敗、IO 流未釋放、ThreadLocal 沒有 remove。如果是內(nèi)存溢出而非泄漏一般是大促流量打上來導(dǎo)致對象瞬間暴增這種時(shí)候更常用的手段是調(diào)整堆參數(shù)、增加機(jī)器、優(yōu)化批量查詢邏輯。我記得有一次真實(shí)排查一個(gè)定時(shí)任務(wù)每天凌晨跑批數(shù)據(jù)量增長后頻繁 Full GC每次 Full GC 后老年代還是很快被打滿。用jmap看堆發(fā)現(xiàn)一個(gè)ArrayList里存了幾百萬個(gè)LogRecord對象。根因是批量處理失敗后的重試邏輯里沒有分批重試時(shí)把失敗批次和積壓數(shù)據(jù)全部加載進(jìn)內(nèi)存再處理。最后改成游標(biāo)式分批加載同時(shí)限制最大重試批次大小問題就消失了。這類經(jīng)驗(yàn)在面試?yán)镏v出來遠(yuǎn)比背誦參數(shù)列表有說服力。3. 并發(fā)編程不只是會(huì)用鎖而是理解鎖3.1 volatile 與 synchronized 的底層運(yùn)作機(jī)制并發(fā)這塊是三到五年經(jīng)驗(yàn)的 Java 工程師最常被深挖的地方。先來看最基礎(chǔ)也最關(guān)鍵的一道題“volatile 和 synchronized 有什么區(qū)別”volatile 有兩個(gè)語義保證可見性和禁止指令重排序但它不保證原子性?？梢娦钥康氖莾?nèi)存屏障加緩存一致性協(xié)議一個(gè)線程修改了 volatile 變量后會(huì)強(qiáng)制將修改寫回主內(nèi)存并讓其他線程中該變量的緩存行失效。禁止指令重排序則是在讀寫 volatile 變量的地方插入內(nèi)存屏障防止編譯器和 CPU 對指令進(jìn)行亂序優(yōu)化。典型的應(yīng)用場景就是雙重檢查鎖單例模式中的instance字段沒有 volatile 的話可能出現(xiàn)一個(gè)線程拿到半初始化對象的問題原因在于“分配內(nèi)存并設(shè)置引用”和“調(diào)用構(gòu)造方法初始化對象”這兩個(gè)步驟可能被重排序。synchronized 則是對一段代碼塊或者一個(gè)方法加鎖。它從 JDK 6 開始做了大量優(yōu)化鎖的狀態(tài)從無鎖到偏向鎖、輕量級(jí)鎖、重量級(jí)鎖是一個(gè)逐漸膨脹的過程。偏向鎖的意思是“這個(gè)鎖大概率只被一個(gè)線程訪問”于是就在對象頭里記錄持有者的線程 ID省掉 CAS一旦有其他線程競爭就升級(jí)成輕量級(jí)鎖通過 CAS 在棧幀中記錄鎖記錄的地址去競爭競爭激烈時(shí)升級(jí)成重量級(jí)鎖未獲得鎖的線程進(jìn)入阻塞隊(duì)列涉及操作系統(tǒng)用戶態(tài)和內(nèi)核態(tài)切換代價(jià)最大?，F(xiàn)在的 JDK 版本已經(jīng)逐步廢棄了偏向鎖但理解這種演變過程仍然很重要因?yàn)樗w現(xiàn)了 JVM 的一個(gè)核心設(shè)計(jì)思路針對“鎖競爭程度不同”的情況用不同代價(jià)的方案去適配。追問的進(jìn)階題往往長這樣“一個(gè)方法里現(xiàn)在既有讀操作又有寫操作全加上 synchronized 會(huì)不會(huì)性能很差怎么優(yōu)化”這就引出了讀寫鎖、樂觀鎖、CAS、ConcurrentHashMap 分段設(shè)計(jì)等一堆知識(shí)。我建議回答的時(shí)候主動(dòng)往“鎖的粒度”和“并發(fā)數(shù)據(jù)結(jié)構(gòu)”這兩個(gè)方向靠面試官會(huì)順著你的話繼續(xù)深入答到點(diǎn)上就是加分。3.2 CAS 的原理與 ABA 問題CAS全稱 Compare And Swap可以說是并發(fā)編程的基石之一。它的操作是比較內(nèi)存中的值和期望值如果相等就更新成新值整個(gè)比較加更新在硬件層面是不可分割的。CAS 避免了鎖帶來的線程掛起和恢復(fù)開銷但它不是沒有問題。第一CAS 如果一直失敗會(huì)一直自旋重試在高并發(fā)下會(huì)白白消耗 CPU。第二CAS 只能保證一個(gè)共享變量的原子操作操作多個(gè)共享變量時(shí)需要加鎖或者用 AtomicReference 把它們封裝成一個(gè)對象。第三就是著名的 ABA 問題線程 1 讀到值 A線程 2 把 A 改成 B 又改回 A線程 1 再 CAS 時(shí)發(fā)現(xiàn)還是 A于是認(rèn)為沒有變化就繼續(xù)操作了。如果這個(gè)過程中其他線程對數(shù)據(jù)結(jié)構(gòu)產(chǎn)生了影響就可能出問題。ABA 問題怎么解決經(jīng)典方案是為變量加上版本號(hào)每次修改版本號(hào)加 1。Java 里的AtomicStampedReference就是干這個(gè)的它同時(shí)持有引用和版本戳。比如一個(gè)賬戶余額線程 A 看到余額是 100線程 B 轉(zhuǎn)進(jìn) 50 變成 150又轉(zhuǎn)出 50 變回 100如果沒有版本號(hào)線程 A 會(huì)以為中間沒人動(dòng)過這在某些計(jì)費(fèi)場景下會(huì)出大問題。用AtomicStampedReference就能感知到版本的變更。不過實(shí)踐中大部分 ABA 場景其實(shí)影響不大比如店鋪庫存這種最終還是看當(dāng)前值的地方它更關(guān)心的是即時(shí)狀態(tài)。這點(diǎn)你主動(dòng)說出來反而會(huì)顯得有真實(shí)項(xiàng)目判斷力。3.3 線程池的核心參數(shù)與真實(shí)調(diào)優(yōu)場景線程池面試題問得極其高頻核心就是那七個(gè)參數(shù)corePoolSize、maximumPoolSize、keepAliveTime、workQueue、threadFactory、handler還有一個(gè) BlockingQueue 的實(shí)現(xiàn)選擇。很多人把參數(shù)背得很熟但一追問“你這幾個(gè)參數(shù)在線上怎么定的”就卡住了。先理一遍流程提交任務(wù)后當(dāng)前線程數(shù)小于核心線程數(shù)就創(chuàng)建新線程執(zhí)行超過核心線程數(shù)任務(wù)先進(jìn)入隊(duì)列隊(duì)列也滿了繼續(xù)創(chuàng)建線程直到最大線程數(shù)再滿執(zhí)行拒絕策略。這里最容易被誤解的是“corePoolSize 滿了之后是擴(kuò)容線程而不是等隊(duì)列滿直接拒”。線程數(shù)從 core 擴(kuò)展到 max 的前提是隊(duì)列已滿。拒絕策略有四種AbortPolicy是直接拋異常CallerRunsPolicy是讓提交任務(wù)的線程自己跑DiscardPolicy是靜默丟棄DiscardOldestPolicy是丟棄隊(duì)列里最老的任務(wù)。實(shí)際項(xiàng)目里我一般推薦CallerRunsPolicy它不會(huì)丟任務(wù)同時(shí)也天然提供了一種背壓機(jī)制當(dāng)線程池飽和時(shí)調(diào)用方線程被迫執(zhí)行任務(wù)就自然放慢了提交速度。參數(shù)怎么定要看任務(wù)是 CPU 密集型還是 IO 密集型。CPU 密集型期望核心線程數(shù)接近 CPU 核數(shù)通常是N1IO 密集型因?yàn)榇蟛糠謺r(shí)間在等待網(wǎng)絡(luò)或磁盤線程數(shù)可以多一點(diǎn)常用公式是N * (1 等待時(shí)間 / 計(jì)算時(shí)間)。我曾經(jīng)調(diào)過一個(gè)報(bào)表導(dǎo)出服務(wù)壓測時(shí)線程數(shù)從 20 加到 50吞吐量不升反降因?yàn)榇罅烤€程同時(shí)爭搶數(shù)據(jù)庫連接連接池先成了瓶頸。后來把思路反過來先定數(shù)據(jù)庫連接池上限再反推線程池大小同時(shí)把導(dǎo)出任務(wù)拆成更細(xì)的批次放入隊(duì)列最終吞吐量反而翻倍。面試?yán)锬苤v清楚這類權(quán)衡比單純背公式有價(jià)值得多。4. Spring 與 Spring Boot框架題背后的設(shè)計(jì)思想4.1 Bean 的生命周期與三級(jí)緩存解決循環(huán)依賴Spring 題目現(xiàn)在普遍向源碼靠攏。第一個(gè)高頻題“Spring 中 Bean 的生命周期是什么”簡單概括就是實(shí)例化前階段BeanPostProcessor 的初始化前置處理、實(shí)例化、屬性填充、初始化InitializingBean、init-method、使用、銷毀。但最好把這個(gè)流程掛到具體接口上去理解。比如BeanPostProcessor的postProcessBeforeInitialization和postProcessAfterInitialization分別會(huì)在初始化前后被調(diào)用AOP 的代理對象就是在postProcessAfterInitialization這個(gè)階段生成的。Autowired依賴注入發(fā)生在屬性填充階段而PostConstruct注解是在屬性填充完成之后才執(zhí)行。理解了這個(gè)順序你就明白了為什么在構(gòu)造方法里直接使用Autowired屬性會(huì)拿到 null因?yàn)闃?gòu)造方法執(zhí)行時(shí)機(jī)早于屬性填充。循環(huán)依賴問題也非常經(jīng)典“Spring 怎么解決循環(huán)依賴”注意Spring 解決的是單例 Bean 的 setter 注入循環(huán)依賴構(gòu)造器注入的循環(huán)依賴它解決不了會(huì)直接拋BeanCurrentlyInCreationException。Spring 的做法是三級(jí)緩存第一級(jí)是singletonObjects存放完整的單例 Bean第二級(jí)是earlySingletonObjects存放提前暴露的、還沒完成屬性填充的半成品對象第三級(jí)是singletonFactories存放 ObjectFactory。為什么需要第三級(jí)而不是直接提前創(chuàng)建完整對象因?yàn)榇蟛糠?Bean 在創(chuàng)建后期會(huì)被動(dòng)態(tài)代理如果二級(jí)緩存直接放原始對象后續(xù)代理對象就沒有機(jī)會(huì)替換了。三級(jí)緩存中存的是 ObjectFactory在真正暴露的時(shí)候才決定是返回原始對象還是代理對象這樣既保證了單例語義又給 AOP 留了口子。答出這一層面試官通常會(huì)比較滿意。4.2 AOP 的底層代理機(jī)制與失效場景AOP 在 Spring 家族里的實(shí)踐非常廣泛從聲明式事務(wù)到日志切面、權(quán)限控制再到Async底層都離不開動(dòng)態(tài)代理。高頻問題就是“JDK 動(dòng)態(tài)代理和 CGLIB 有什么區(qū)別Spring 里會(huì)怎么選”JDK 動(dòng)態(tài)代理基于接口通過Proxy.newProxyInstance生成一個(gè)實(shí)現(xiàn)同樣接口的代理類調(diào)用方法時(shí)通過InvocationHandler轉(zhuǎn)發(fā)CGLIB 則通過繼承目標(biāo)類生成子類重寫目標(biāo)方法。JDK 自帶的代理要求目標(biāo)類必須有接口而 CGLIB 可以代理沒有接口的類。Spring Boot 2.x 之后默認(rèn)使用的是 CGLIB也就是通過proxyTargetClasstrue因?yàn)楝F(xiàn)在很多業(yè)務(wù)類根本不設(shè)計(jì)接口直接 CGLIB 更省心。但如果目標(biāo)方法是 final 的或者類是 final 的CGLIB 也代理不了因?yàn)樽宇悷o法重寫 final 方法。AOP 失效的經(jīng)典場景是什么最典型的就是同類內(nèi)部方法調(diào)用。Spring 的代理只在從外部調(diào)用 Bean 的方法時(shí)生效如果 Bean 內(nèi)部一個(gè)方法調(diào)用另一個(gè)帶Transactional的方法走的是this引用沒有經(jīng)過代理對象事務(wù)就失效了。解決辦法有三個(gè)注入自身代理、拆到另一個(gè) Bean 里、使用AopContext.currentProxy()。這些細(xì)節(jié)在面試?yán)飳儆凇按鹜暝碇笾鲃?dòng)補(bǔ)充的提分點(diǎn)”。還有個(gè)容易混淆的點(diǎn)Spring 的事務(wù)和Async用的是同一個(gè)代理機(jī)制所以很多Async失效的問題根因和事務(wù)失效是一模一樣的。4.3 Spring 事務(wù)失效的八大典型場景“Spring 事務(wù)在什么情況下會(huì)失效”這是大廠面試官比較愛出的“場景題”因?yàn)闃I(yè)務(wù)項(xiàng)目里事務(wù)踩坑太常見了。我總結(jié)下來有八個(gè)典型場景。第一方法不是 public 的Spring 默認(rèn)用 CGLIB 代理代理只能增強(qiáng) public 方法非 public 方法的事務(wù)注解不生效。第二同類內(nèi)部調(diào)用也就是前面說的不走代理。第三異常被 catch 住吞掉了事務(wù)感知不到異常自然無法回滾。第四拋出的異常類型不是 RuntimeException而是 checked Exception比如IOExceptionSpring 默認(rèn)只對 RuntimeException 回滾checked 異常不會(huì)觸發(fā)回滾除非在Transactional里顯式指定rollbackFor。第五數(shù)據(jù)庫引擎不支持事務(wù)比如 MySQL 用了 MyISAM 表。第六多線程調(diào)用一個(gè)方法內(nèi)開啟子線程去執(zhí)行另一個(gè)事務(wù)方法因?yàn)槭聞?wù)和線程綁定子線程里的事務(wù)不會(huì)和主線程合并而且子線程拋異常也不會(huì)回滾主線程。第七事務(wù)方法里使用this調(diào)用切面相關(guān)的內(nèi)部方法。第八類沒有被 Spring 管理也就是忘了加Service之類的注解。每個(gè)場景背后其實(shí)都指向同一個(gè)核心理解Spring 事務(wù)的本質(zhì)是 AOP本質(zhì)是通過代理攔截目標(biāo)方法在方法執(zhí)行前開啟事務(wù)、在方法返回或拋出異常時(shí)提交或回滾。把這個(gè)本質(zhì)講清楚八個(gè)場景根本不用背自己就能推導(dǎo)出來。5. MySQL 與 Redis數(shù)據(jù)層的進(jìn)階追問5.1 索引為什么選 B 樹什么時(shí)候索引會(huì)失效MySQL 的索引是必考內(nèi)容而且角度越來越刁鉆。最基本的題目是“InnoDB 的索引為什么用 B 樹而不用 B 樹或者紅黑樹”B 樹相比 B 樹的優(yōu)勢是數(shù)據(jù)只存儲(chǔ)在葉子節(jié)點(diǎn)內(nèi)部節(jié)點(diǎn)只存鍵值所以單頁可以容納更多索引項(xiàng)樹的層級(jí)更矮。三層 B 樹大概可以存儲(chǔ)千萬級(jí)別到億級(jí)別的數(shù)據(jù)量加上葉子節(jié)點(diǎn)之間有鏈表連接做范圍查詢非常高效。紅黑樹是二叉樹高度遠(yuǎn)高于 B 樹磁盤 IO 次數(shù)多完全不適合數(shù)據(jù)庫這種以磁盤塊為單位的訪問模式。哈希索引雖然能 O(1) 做等值查詢但沒法做范圍查詢也無法利用最左前綴。這是從數(shù)據(jù)結(jié)構(gòu)特性去理解 MySQL 選型的核心邏輯。接著就會(huì)被問二級(jí)索引和回表。InnoDB 是聚簇索引主鍵索引的葉子節(jié)點(diǎn)直接存整行數(shù)據(jù)二級(jí)索引的葉子節(jié)點(diǎn)存的是主鍵值。用二級(jí)索引查詢時(shí)先找到主鍵再回聚簇索引查一次這個(gè)過程叫回表。如果查詢的列正好全部在二級(jí)索引里就形成了覆蓋索引不需要回表性能會(huì)好很多。這就是為什么查詢建議只 select 必要列而不是無腦 select *因?yàn)橐坏纤饕獾牧懈采w索引就用不上了。索引失效的場景也是必背清單對索引列使用函數(shù)或者運(yùn)算發(fā)生隱式類型轉(zhuǎn)換比如索引列是字符串查詢條件卻用了數(shù)字使用模糊匹配且通配符在前面LIKE %abc無法走索引LIKE abc%可以使用OR連接非索引列聯(lián)合索引不滿足最左前綴規(guī)則。這些規(guī)則背下來是基礎(chǔ)但更關(guān)鍵的是能從“索引本身就是一種有序結(jié)構(gòu)”的角度去理解為什么失效。比如對索引列做運(yùn)算本質(zhì)上是改變了索引列的值原有排序無法再用自然就失效了。5.2 MySQL 的鎖機(jī)制與事務(wù)隔離級(jí)別MySQL 并發(fā)控制的相關(guān)問題核心圍繞事務(wù)隔離級(jí)別和鎖。事務(wù)的四大特性 ACID 人人都能背關(guān)鍵是隔離級(jí)別。MySQL 默認(rèn)的隔離級(jí)別是REPEATABLE READ也就是可重復(fù)讀。它通過多版本并發(fā)控制MVCC實(shí)現(xiàn)快照讀同時(shí)用next-key lock解決幻讀問題。這里的 next-key lock 是記錄鎖和間隙鎖的組合它鎖定的不只是某一行還包括這行之前的間隙這樣別的事務(wù)就無法在間隙里插入新數(shù)據(jù)。理解了這一點(diǎn)就能解釋為什么在可重復(fù)讀級(jí)別下某些范圍查詢會(huì)把不相干的記錄也鎖住從而可能引發(fā)死鎖。面試時(shí)一個(gè)更高頻的追問是“READ COMMITTED和REPEATABLE READ的區(qū)別是什么”簡單說前者每次讀取都生成新的快照所以同一事務(wù)內(nèi)兩次查詢結(jié)果可能不同后者在事務(wù)開始時(shí)就生成快照后續(xù)讀的是同一個(gè)快照所以能重復(fù)讀。但要注意可重復(fù)讀的快照讀并不能完全避免幻影讀下的寫沖突需要結(jié)合 next-key lock 才能做完整防護(hù)。這也是為什么很多人說 MySQL 在默認(rèn)隔離級(jí)別下其實(shí)已經(jīng)基本做到了類似串行化隔離級(jí)別下才有的防幻讀效果。關(guān)于死鎖面試官很喜歡讓候選人現(xiàn)場分析。比如兩條 update 語句以相反順序鎖定兩行數(shù)據(jù)就可能形成互相等待。排查死鎖的常規(guī)動(dòng)作是執(zhí)行SHOW ENGINE INNODB STATUS查看 LATEST DETECTED DEADLOCK 部分找到持鎖的事務(wù)和等待鎖的事務(wù)。業(yè)務(wù)上規(guī)避死鎖的一個(gè)重要思路是讓所有事務(wù)以固定的順序訪問表和行。5.3 Redis 緩存穿透、擊穿、雪崩的應(yīng)對方案Redis 相關(guān)的場景題最經(jīng)典的就是緩存三大問題。緩存穿透是查詢一個(gè)根本不存在的 key請求打到數(shù)據(jù)庫上如果這種請求量很大數(shù)據(jù)庫壓力就會(huì)異常。解決思路是緩存空值把不存在的 key 也緩存一下但要設(shè)置較短的過期時(shí)間更好的是用布隆過濾器在緩存前面加一道判斷把明顯不存在的 key 直接攔截掉。注意布隆過濾器有誤判率它會(huì)告訴你“一定不存在”和“可能存在”誤判不會(huì)漏掉真實(shí)存在的 key只會(huì)把極少數(shù)不存在的 key 放過去這在緩存場景下是可接受的。緩存擊穿是某個(gè)熱點(diǎn) key 在過期瞬間大量并發(fā)請求同時(shí)打到數(shù)據(jù)庫。處理辦法有三個(gè)互斥鎖也就是只讓一個(gè)請求去重建緩存其他請求等待邏輯過期把 value 里塞一個(gè)過期時(shí)間字段異步線程去更新緩存請求先拿舊值返回永不過期加后臺(tái)定時(shí)刷新?；コ怄i實(shí)現(xiàn)簡單但存在串行化問題邏輯過期能做到最終一致且不阻塞請求但對業(yè)務(wù)代碼有侵入。緩存雪崩是大量 key 同時(shí)過期或者 Redis 實(shí)例宕機(jī)導(dǎo)致請求全部落到數(shù)據(jù)庫。應(yīng)對策略包括過期時(shí)間加一個(gè)隨機(jī)值避免同一時(shí)刻集體過期用多級(jí)緩存本地緩存加分布式緩存Redis 高可用部署加上熔斷降級(jí)策略。面試官通常會(huì)追問“如果 Redis 掛了你怎么辦”這時(shí)候不要只答“等它恢復(fù)”而要把兜底方案講出來本地緩存臨時(shí)頂上、對非核心接口做降級(jí)、數(shù)據(jù)庫提前做讀寫分離擴(kuò)容。6. 分布式與場景題沒有標(biāo)準(zhǔn)答案的加分項(xiàng)6.1 分布式鎖Redis 鎖、ZooKeeper 鎖與 Redlock 之爭到了這個(gè)層面面試題逐漸變成“開放題”。第一個(gè)典型的開放問題是“你在項(xiàng)目里怎么設(shè)計(jì)一個(gè)分布式鎖”如果用的是 Redis最簡單的方案是SET key value EX seconds NX只有鍵不存在時(shí)才能設(shè)置成功過期時(shí)間保證鎖不會(huì)永久持有。但這里面有幾個(gè)坑。第一個(gè)坑是鎖的 value 必須帶上一個(gè)唯一標(biāo)識(shí)比如 UUID釋放鎖時(shí)要先比較 value 再刪除否則可能出現(xiàn)線程 A 的鎖到期自動(dòng)釋放線程 B 拿到了新鎖然后 A 又去把 B 的鎖刪掉的情況。第二個(gè)坑是主從切換時(shí)的丟鎖問題Redis 主節(jié)點(diǎn)宕機(jī)后從節(jié)點(diǎn)頂上如果鎖還沒來得及同步到從節(jié)點(diǎn)鎖就丟了。Redlock 算法試圖通過向多個(gè)獨(dú)立 Redis 節(jié)點(diǎn)加鎖來解決這個(gè)問題但它在極端情況下仍有爭議比如發(fā)生時(shí)鐘跳躍時(shí)。面試時(shí)主動(dòng)講出 Redlock 的適用場景和爭議點(diǎn)會(huì)讓面試官覺得你真的在生產(chǎn)環(huán)境里思考過。如果用 ZooKeeper 做分布式鎖常見做法是創(chuàng)建臨時(shí)順序節(jié)點(diǎn)每個(gè)客戶端注冊后得到一個(gè)序號(hào)只有序號(hào)最小的持有鎖其他客戶端監(jiān)聽前一個(gè)節(jié)點(diǎn)。臨時(shí)節(jié)點(diǎn)的好處是客戶端宕機(jī)后節(jié)點(diǎn)自動(dòng)消失不會(huì)出現(xiàn) Redis 鎖那種“死鎖后只能等過期”的問題。但 ZooKeeper 鎖的性能不如 Redis而且每次加鎖都要多次網(wǎng)絡(luò)交互。實(shí)際選型邏輯是要求高可靠性和自動(dòng)釋放就選 ZooKeeper追求性能和簡單性就選 Redis。這個(gè)問題沒有唯一答案你把自己項(xiàng)目的訪問量、可用性要求、已有基礎(chǔ)設(shè)施說清楚就是完整的回答。6.2 接口冪等性與重復(fù)提交的處理“怎么保證接口的冪等性”是分布式場景的?？?。面試題包裝通常是“用戶快速點(diǎn)了兩次提交后端重復(fù)扣款了怎么避免”。冪等性設(shè)計(jì)的核心思想是讓一次和多次請求的效果相同。最簡單也最可靠的方法是在數(shù)據(jù)庫層面加唯一約束比如訂單號(hào)唯一、支付流水號(hào)唯一。第一次插入成功第二次插入會(huì)因?yàn)槲ㄒ绘I沖突而失敗業(yè)務(wù)代碼里捕獲這個(gè)沖突返回“處理中”或者“已成功”即可。對于更新場景可以用樂觀鎖表里加一個(gè)版本號(hào)update 時(shí)帶上version ?條件更新成功后版本號(hào)加一更新行數(shù)為 0 就說明版本不匹配直接丟棄該次請求。還有一種思路是使用狀態(tài)機(jī)。比如支付單的狀態(tài)從“待支付”到“支付中”再到“已支付”是一個(gè)不可逆的過程業(yè)務(wù)代碼里通過update ... where status 待支付這樣的條件更新來保證同一狀態(tài)只能被成功推進(jìn)一次。這種方案的優(yōu)點(diǎn)是語義清晰缺點(diǎn)是業(yè)務(wù)代碼里到處都要寫狀態(tài)判斷侵入性強(qiáng)。面試?yán)锬阒灰v清楚場景匹配哪種方案比如“下單用唯一鍵扣庫存用樂觀鎖長流程用狀態(tài)機(jī)”就比只背一個(gè)方案要出彩。6.3 消息隊(duì)列的可靠性不丟、不重、有序消息隊(duì)列一定是分布式簡歷里的高頻組件。高頻題是“怎么保證消息不丟失”回答這個(gè)問題要分三段來拆。生產(chǎn)端使用同步發(fā)送并等待 Broker 確認(rèn)或者開啟事務(wù)消息、確認(rèn)回調(diào)保證消息真正到達(dá) BrokerBroker 端開啟持久化把消息刷到磁盤并且對應(yīng)的隊(duì)列設(shè)置為持久化隊(duì)列消費(fèi)端關(guān)閉自動(dòng) ack改成手動(dòng) ack處理成功后再確認(rèn)。只要三段每一段都有確認(rèn)機(jī)制消息就能基本做到不丟。注意消息隊(duì)列的不丟是有條件的不丟不同中間件默認(rèn)配置不一樣比如 Kafka 的配置要關(guān)注acks、min.insync.replicas和enable.auto.commit三個(gè)參數(shù)?！霸趺幢ＷC不重復(fù)消費(fèi)”這才是更難的問題。因?yàn)榫W(wǎng)絡(luò)重試、消費(fèi)者宕機(jī)再恢復(fù)都會(huì)導(dǎo)致同一消息被投遞多次。消息中間件只能保證至少一次語義無法保證剛好一次所以業(yè)務(wù)側(cè)必須做冪等這又繞回了上一個(gè)話題數(shù)據(jù)庫唯一鍵、Redis setnx、狀態(tài)機(jī)都天然可以用來做消費(fèi)冪等?！跋⒃趺幢ＷC順序性”Kafka 的答案是分區(qū)有序同一業(yè)務(wù) key 的消息發(fā)到同一個(gè)分區(qū)消費(fèi)者在分區(qū)內(nèi)順序處理。但一旦有多個(gè)消費(fèi)者并發(fā)消費(fèi)同一個(gè)分區(qū)順序就會(huì)亂。所以實(shí)踐中通常還要配合“單分區(qū)單消費(fèi)者”或者把并發(fā)度收斂再在業(yè)務(wù)側(cè)用狀態(tài)機(jī)做兜底。這三類問題串起來答能明顯增加面試的完整度。7. 面試現(xiàn)場加減分項(xiàng)聊幾個(gè)實(shí)操心得7.1 答題節(jié)奏與“主動(dòng)引導(dǎo)”最后再分享幾個(gè)我既作為面試官、也作為被面試者總結(jié)出來的實(shí)操體會(huì)。第一答題要學(xué)會(huì)分層。面試官問一個(gè)概念先給一句話結(jié)論再展開細(xì)節(jié)不要上來就倒一大堆。比如問“HashMap 和 ConcurrentHashMap 有什么區(qū)別”先說“線程安全的差異和底層實(shí)現(xiàn)不同”再分別展開。提綱挈領(lǐng)的答法讓面試官可以隨時(shí)打斷你或者沿著你的話問下去節(jié)奏更可控。第二主動(dòng)暴露“邊界”。說完了常規(guī)實(shí)現(xiàn)補(bǔ)一句“但是這個(gè)方案在某某場景下有局限”面試官通常會(huì)被帶著往你準(zhǔn)備好的方向問。比如聊 Redis 分布式鎖你主動(dòng)提主從切換丟鎖問題話題就很自然滑向 Redlock 和 CAP這些都是你能提前準(zhǔn)備的。千萬不要只等面試官出招那樣很容易被問到知識(shí)盲區(qū)。第三不會(huì)的題要表現(xiàn)推導(dǎo)過程。大廠面試官其實(shí)不是非要你每道題都答對他們更關(guān)注你面對不確定問題的反應(yīng)。遇到不會(huì)的題先把已知的部分拆解出來再嘗試類比到熟悉的東西上。比如讓你說一個(gè)沒接觸過的中間件的實(shí)現(xiàn)原理你可以從“它解決什么問題、有什么類似物、數(shù)據(jù)怎么流轉(zhuǎn)”三個(gè)角度推。哪怕推得不夠準(zhǔn)確也比沉默或瞎編強(qiáng)。7.2 簡歷和項(xiàng)目經(jīng)驗(yàn)的技術(shù)錨點(diǎn)還有一個(gè)容易被低估的環(huán)節(jié)項(xiàng)目描述里提到的每個(gè)技術(shù)名詞都要準(zhǔn)備好被追問。寫“用了 Redis 緩存”就要準(zhǔn)備緩存穿透、擊穿、雪崩、緩存一致性這幾個(gè)問題寫“用消息隊(duì)列做了異步解耦”就要準(zhǔn)備可靠性、順序性、積壓處理這些問題。項(xiàng)目里用到了什么技術(shù)面試官默認(rèn)你會(huì)往深了聊所以不要在簡歷上堆不認(rèn)識(shí)的名詞。我建議把項(xiàng)目經(jīng)驗(yàn)按“背景、方案、難點(diǎn)、結(jié)果”四段式準(zhǔn)備其中“難點(diǎn)”是重中之重。難點(diǎn)最好是那種能在技術(shù)層面體現(xiàn)出取舍的問題比如“訂單量上漲后數(shù)據(jù)庫查詢變慢你是怎么優(yōu)化的”。這種問題既考察技術(shù)寬度也考察你是不是真的參與了這個(gè)項(xiàng)目。把優(yōu)化前后的數(shù)據(jù)對比也準(zhǔn)備好有數(shù)據(jù)支撐的回答說服力完全不一樣。準(zhǔn)備面試本質(zhì)上就是在整理自己的知識(shí)體系。刷題只是引子真正重要的還是把每個(gè)問題的“為什么”想清楚。我自己的體會(huì)是把上面這幾條線吃透不管面試題拿到的是哪套組合都能找到對應(yīng)的思考路徑。把心態(tài)放穩(wěn)把基礎(chǔ)夯實(shí)金三銀四的機(jī)會(huì)自然會(huì)落到有準(zhǔn)備的人手里。 Java大廠面試高頻考點(diǎn)解析：集合、JVM、并發(fā)、MySQL與分布式
每到二月底技術(shù)社群里問得最多的就不再是什么框架原理了而是一句“金三銀四沖大廠Java面試題現(xiàn)在該看什么”。我在面試官的位置上坐過也在候選人那一側(cè)被面過幾十輪給一個(gè)比較實(shí)在的結(jié)論大廠面試再怎么換風(fēng)格Java基礎(chǔ)、并發(fā)、JVM、Spring、數(shù)據(jù)存儲(chǔ)、分布式這六個(gè)板塊始終是繞不開的主線。這篇文章不搞那種幾百題的流水賬而是把我自己印象里出現(xiàn)頻率最高、也最容易翻車的幾類 Java 面試題連同面試官的追問邏輯和參考回答一起拆開講。按這條線往下過不敢說穩(wěn)過但至少不會(huì)踩空。1. Java基礎(chǔ)題看似簡單卻最容易翻車的考點(diǎn)1.1 從“”到equals再到hashCode一條線理清楚基礎(chǔ)題在大廠面試?yán)飶膩聿蝗毕芏嗳饲∏煸谧詈唵蔚念}目上。先看這個(gè)經(jīng)典問題“和equals有什么區(qū)別”如果作用于基本數(shù)據(jù)類型比較的是值本身如果作用于引用類型比較的是兩個(gè)引用是否指向同一個(gè)對象也就是內(nèi)存地址。而equals在沒有被重寫的情況下行為等同于但通常我們會(huì)重寫它來定義“邏輯相等”。比如兩個(gè)User對象只要身份證號(hào)相同就算同一個(gè)人這時(shí)候就應(yīng)該重寫equals而不是直接比較地址。面試官問完這一個(gè)十有八九會(huì)接一句“那equals和hashCode是什么關(guān)系”這里有個(gè)硬規(guī)矩重寫equals就必須重寫hashCode而且必須保證如果a.equals(b)為 true那么a.hashCode()必須等于b.hashCode()。原因其實(shí)很實(shí)際HashMap這類集合是靠hashCode定位桶再用equals去比較桶內(nèi)元素。如果你只重寫equals不重寫hashCode兩個(gè)邏輯上相等的 key 會(huì)落在不同的桶里HashMap就會(huì)存進(jìn)去兩份這顯然就破壞了 Map 的語義。順著這條線面試官還會(huì)繼續(xù)加碼“String 的equals和hashCode是怎么實(shí)現(xiàn)的String 的不變性有什么好處”String 類內(nèi)部用一個(gè)char數(shù)組或者byte數(shù)組存字符它的equals先比較引用、再比較長度、最后逐個(gè)字符比較。hashCode則是s[0]*31^(n-1) s[1]*31^(n-2) ...這種散列公式用 31 是因?yàn)樗且粋€(gè)奇質(zhì)數(shù)在乘法運(yùn)算里沖突概率相對低而且 JVM 對31 * i有優(yōu)化編譯器會(huì)把它轉(zhuǎn)成(i 5) - i位運(yùn)算比乘法快。String 的不變性讓它可以安全地被字符串常量池復(fù)用也保證了作為 HashMap 的 key 時(shí)哈希值不會(huì)變。這個(gè)問題的意義不在背答案而在考察你有沒有把“數(shù)據(jù)結(jié)構(gòu)”和“語言特性”聯(lián)系起來思考的習(xí)慣。1.2 HashMap 的底層結(jié)構(gòu)、擴(kuò)容機(jī)制與并發(fā)隱患HashMap 是 Java 面試?yán)锂?dāng)之無愧的“題王”。它的回答版本也在演進(jìn)JDK 7 及以前是數(shù)組加鏈表JDK 8 開始變成數(shù)組加鏈表加紅黑樹。默認(rèn)初始容量是 16負(fù)載因子是 0.75。什么意思就是當(dāng)元素個(gè)數(shù)超過16 * 0.75 12時(shí)會(huì)觸發(fā)擴(kuò)容容量翻倍到 32。為什么負(fù)載因子取 0.75 而不是 1 或者 0.5這是空間和時(shí)間的折中。負(fù)載因子越高空間利用率越高但哈希沖突概率變大鏈表長度增加查詢效率下降負(fù)載因子太低則空間浪費(fèi)太多。0.75 是官方在大量測試后給的經(jīng)驗(yàn)值。鏈表轉(zhuǎn)紅黑樹的閾值是 8樹轉(zhuǎn)回鏈表的閾值是 6之所以不是同一個(gè)數(shù)是為了避免元素在邊界來回浮動(dòng)時(shí)頻繁轉(zhuǎn)換。為什么閾值取 8本質(zhì)上是一個(gè)概率問題在隨機(jī)哈希函數(shù)下鏈表節(jié)點(diǎn)數(shù)服從泊松分布負(fù)載因子 0.75 時(shí)桶中鏈表長度達(dá)到 8 的概率已經(jīng)低于千萬分之一所以 8 是一個(gè)“幾乎不會(huì)出現(xiàn)但出現(xiàn)了就說明哈希分布極差”的信號(hào)。HashMap 的線程不安全是最常被追問的。JDK 7 里并發(fā) put 可能導(dǎo)致擴(kuò)容時(shí)鏈表形成環(huán)一旦 get 那個(gè) key 就會(huì)死循環(huán)CPU 直接飆滿。JDK 8 把頭插法改成了尾插法在一定程度上避免了環(huán)的產(chǎn)生但并發(fā)場景下依然有數(shù)據(jù)覆蓋問題兩個(gè)線程同時(shí)判斷某個(gè) key 不存在同時(shí)插入后寫覆蓋先寫還有一種情況是 put 過程中檢查到容量不夠多個(gè)線程同時(shí)擴(kuò)容導(dǎo)致數(shù)據(jù)丟失。所以并發(fā)場景不要用 HashMap要用ConcurrentHashMap。JDK 8 的 ConcurrentHashMap 放棄了 JDK 7 的分段鎖設(shè)計(jì)改為 CAS 加 synchronized 鎖住數(shù)組的單個(gè)槽位粒度更細(xì)并發(fā)度更高。我自己面試別人的時(shí)候通常會(huì)追問一句“為什么 JDK 8 要把擴(kuò)容后重新散列的算法改成高低位拆分”。JDK 7 擴(kuò)容是對每個(gè)元素重新計(jì)算 hash 再確定新位置JDK 8 優(yōu)化成根據(jù) hash 值新增的那一位是 0 還是 1元素要么留在原索引要么移動(dòng)到“原索引加舊容量”的位置。這樣做既省去了重新計(jì)算 hash 的開銷也減少了元素移動(dòng)次數(shù)。這個(gè)問題能答上來說明你確實(shí)讀過源碼而不是只看面經(jīng)。2. JVM 與內(nèi)存模型拉開差距的核心區(qū)2.1 運(yùn)行時(shí)數(shù)據(jù)區(qū)域與對象創(chuàng)建機(jī)制JVM 這塊可以說是大廠面試的分水嶺。背完“程序計(jì)數(shù)器、虛擬機(jī)棧、本地方法棧、堆、方法區(qū)”這五個(gè)名字只是入門關(guān)鍵是能講清楚每個(gè)區(qū)域里到底發(fā)生了什么。虛擬機(jī)棧管的是方法調(diào)用的過程。每次調(diào)用一個(gè)方法JVM 就會(huì)創(chuàng)建一個(gè)棧幀棧幀里有局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口。方法嵌套調(diào)用的深度是有上限的線程棧深度超過限制就會(huì)拋StackOverflowError。堆則是一切對象實(shí)例和數(shù)組的分配場所也是垃圾回收的主戰(zhàn)場。方法區(qū)在 JDK 8 里被移到了元空間不再使用虛擬機(jī)內(nèi)存而是用本地內(nèi)存這樣設(shè)計(jì)主要是為了避免永久代的OutOfMemoryError因?yàn)樵臻g默認(rèn)只受本機(jī)可用內(nèi)存限制并且字符串常量池在 JDK 7 時(shí)就已經(jīng)移到了堆里。對象的創(chuàng)建過程也經(jīng)常被連環(huán)追問類加載檢查、分配內(nèi)存、初始化零值、設(shè)置對象頭、執(zhí)行構(gòu)造方法。其中分配內(nèi)存那一步指針碰撞和空閑列表分別對應(yīng)“堆內(nèi)存規(guī)整”和“堆內(nèi)存不規(guī)整”兩種情況。如果是并發(fā)創(chuàng)建對象JVM 還需要解決線程安全問題主流做法是 CAS 加失敗重試或者使用線程本地分配緩沖TLAB。能聊到 TLAB 的候選人一般基礎(chǔ)就不會(huì)太差。2.2 垃圾回收算法與主流收集器垃圾回收問的是什么我認(rèn)為核心就兩個(gè)一是怎么判定對象已死二是怎么把垃圾高效清掉。判定對象已死主流答案是基于可達(dá)性分析。從 GC Roots 出發(fā)遍歷引用鏈不能被到達(dá)的對象就可以被回收。GC Roots 包括虛擬機(jī)棧中引用的對象、方法區(qū)中靜態(tài)屬性引用的對象、常量引用的對象、本地方法棧中 JNI 引用的對象等。這里有個(gè)經(jīng)典坑點(diǎn)兩個(gè)對象互相引用但都沒有被外部引用可達(dá)性分析依然能判定它們已死而引用計(jì)數(shù)法做不到所以現(xiàn)代主流的 JVM 都采用可達(dá)性分析。順帶一提面試官很可能繼續(xù)問“強(qiáng)引用、軟引用、弱引用、虛引用的區(qū)別”軟引用在內(nèi)存不足時(shí)會(huì)被回收弱引用在下一次 GC 時(shí)必被回收虛引用完全不影響生命周期只用于對象回收后的通知。回收算法里標(biāo)記-清除會(huì)產(chǎn)生大量碎片標(biāo)記-復(fù)制要浪費(fèi)一半空間標(biāo)記-整理要移動(dòng)對象?，F(xiàn)代的收集器基本都是分代設(shè)計(jì)新生代對象存活率低適合復(fù)制算法老年代對象存活率高適合標(biāo)記-整理或者標(biāo)記-清除。CMS 是第一款并發(fā)收集器它的初衷是減少停頓但犧牲了 CPU 資源并且會(huì)產(chǎn)生浮動(dòng)垃圾最后還因?yàn)闊o法處理碎片化問題在 JDK 9 里被標(biāo)記為廢棄。G1 把堆劃分成一個(gè)個(gè) Region可以做到可預(yù)測的停頓時(shí)間它的核心思路是維護(hù)一個(gè)優(yōu)先級(jí)列表回收價(jià)值最大的 Region 優(yōu)先。再往后就是 ZGC停頓時(shí)間控制在 10 毫秒以內(nèi)但越是新東西面試?yán)飭柕缴疃鹊母怕示驮降鸵驗(yàn)榇蠖鄶?shù)人沒有線上壓測經(jīng)驗(yàn)?zāi)艽鸪觥癎1 的 Region 結(jié)構(gòu)、Mixed GC、Remembered Set”已經(jīng)足夠過關(guān)。2.3 線上 OOM 排查的實(shí)戰(zhàn)套路大廠面試基本不滿足于讓你背概念經(jīng)常會(huì)把問題包裝成場景“線上突然 OOM你怎么處理”這類問題沒有唯一答案但有一套標(biāo)準(zhǔn)動(dòng)作。先看報(bào)錯(cuò)信息是Java heap space還是Metaspace還是Unable to create new native thread定位是哪塊區(qū)域出了問題。然后用jps找到進(jìn)程號(hào)jstat -gcutil看各代的使用率和 GC 頻率jmap -dump:formatb,fileheap.hprof導(dǎo)出堆快照再用 MAT 或者 JProfiler 分析。分析的時(shí)候先看支配樹找到占用內(nèi)存最大的那個(gè)對象再看引用鏈定位到業(yè)務(wù)代碼的哪一行。如果是內(nèi)存泄漏重點(diǎn)關(guān)注是否有全局緩存無限增長、數(shù)據(jù)庫連接關(guān)閉失敗、IO 流未釋放、ThreadLocal 沒有 remove。如果是內(nèi)存溢出而非泄漏一般是大促流量打上來導(dǎo)致對象瞬間暴增這種時(shí)候更常用的手段是調(diào)整堆參數(shù)、增加機(jī)器、優(yōu)化批量查詢邏輯。我記得有一次真實(shí)排查一個(gè)定時(shí)任務(wù)每天凌晨跑批數(shù)據(jù)量增長后頻繁 Full GC每次 Full GC 后老年代還是很快被打滿。用jmap看堆發(fā)現(xiàn)一個(gè)ArrayList里存了幾百萬個(gè)LogRecord對象。根因是批量處理失敗后的重試邏輯里沒有分批重試時(shí)把失敗批次和積壓數(shù)據(jù)全部加載進(jìn)內(nèi)存再處理。最后改成游標(biāo)式分批加載同時(shí)限制最大重試批次大小問題就消失了。這類經(jīng)驗(yàn)在面試?yán)镏v出來遠(yuǎn)比背誦參數(shù)列表有說服力。3. 并發(fā)編程不只是會(huì)用鎖而是理解鎖3.1 volatile 與 synchronized 的底層運(yùn)作機(jī)制并發(fā)這塊是三到五年經(jīng)驗(yàn)的 Java 工程師最常被深挖的地方。先來看最基礎(chǔ)也最關(guān)鍵的一道題“volatile 和 synchronized 有什么區(qū)別”volatile 有兩個(gè)語義保證可見性和禁止指令重排序但它不保證原子性?？梢娦钥康氖莾?nèi)存屏障加緩存一致性協(xié)議一個(gè)線程修改了 volatile 變量后會(huì)強(qiáng)制將修改寫回主內(nèi)存并讓其他線程中該變量的緩存行失效。禁止指令重排序則是在讀寫 volatile 變量的地方插入內(nèi)存屏障防止編譯器和 CPU 對指令進(jìn)行亂序優(yōu)化。典型的應(yīng)用場景就是雙重檢查鎖單例模式中的instance字段沒有 volatile 的話可能出現(xiàn)一個(gè)線程拿到半初始化對象的問題原因在于“分配內(nèi)存并設(shè)置引用”和“調(diào)用構(gòu)造方法初始化對象”這兩個(gè)步驟可能被重排序。synchronized 則是對一段代碼塊或者一個(gè)方法加鎖。它從 JDK 6 開始做了大量優(yōu)化鎖的狀態(tài)從無鎖到偏向鎖、輕量級(jí)鎖、重量級(jí)鎖是一個(gè)逐漸膨脹的過程。偏向鎖的意思是“這個(gè)鎖大概率只被一個(gè)線程訪問”于是就在對象頭里記錄持有者的線程 ID省掉 CAS一旦有其他線程競爭就升級(jí)成輕量級(jí)鎖通過 CAS 在棧幀中記錄鎖記錄的地址去競爭競爭激烈時(shí)升級(jí)成重量級(jí)鎖未獲得鎖的線程進(jìn)入阻塞隊(duì)列涉及操作系統(tǒng)用戶態(tài)和內(nèi)核態(tài)切換代價(jià)最大?，F(xiàn)在的 JDK 版本已經(jīng)逐步廢棄了偏向鎖但理解這種演變過程仍然很重要因?yàn)樗w現(xiàn)了 JVM 的一個(gè)核心設(shè)計(jì)思路針對“鎖競爭程度不同”的情況用不同代價(jià)的方案去適配。追問的進(jìn)階題往往長這樣“一個(gè)方法里現(xiàn)在既有讀操作又有寫操作全加上 synchronized 會(huì)不會(huì)性能很差怎么優(yōu)化”這就引出了讀寫鎖、樂觀鎖、CAS、ConcurrentHashMap 分段設(shè)計(jì)等一堆知識(shí)。我建議回答的時(shí)候主動(dòng)往“鎖的粒度”和“并發(fā)數(shù)據(jù)結(jié)構(gòu)”這兩個(gè)方向靠面試官會(huì)順著你的話繼續(xù)深入答到點(diǎn)上就是加分。3.2 CAS 的原理與 ABA 問題CAS全稱 Compare And Swap可以說是并發(fā)編程的基石之一。它的操作是比較內(nèi)存中的值和期望值如果相等就更新成新值整個(gè)比較加更新在硬件層面是不可分割的。CAS 避免了鎖帶來的線程掛起和恢復(fù)開銷但它不是沒有問題。第一CAS 如果一直失敗會(huì)一直自旋重試在高并發(fā)下會(huì)白白消耗 CPU。第二CAS 只能保證一個(gè)共享變量的原子操作操作多個(gè)共享變量時(shí)需要加鎖或者用 AtomicReference 把它們封裝成一個(gè)對象。第三就是著名的 ABA 問題線程 1 讀到值 A線程 2 把 A 改成 B 又改回 A線程 1 再 CAS 時(shí)發(fā)現(xiàn)還是 A于是認(rèn)為沒有變化就繼續(xù)操作了。如果這個(gè)過程中其他線程對數(shù)據(jù)結(jié)構(gòu)產(chǎn)生了影響就可能出問題。ABA 問題怎么解決經(jīng)典方案是為變量加上版本號(hào)每次修改版本號(hào)加 1。Java 里的AtomicStampedReference就是干這個(gè)的它同時(shí)持有引用和版本戳。比如一個(gè)賬戶余額線程 A 看到余額是 100線程 B 轉(zhuǎn)進(jìn) 50 變成 150又轉(zhuǎn)出 50 變回 100如果沒有版本號(hào)線程 A 會(huì)以為中間沒人動(dòng)過這在某些計(jì)費(fèi)場景下會(huì)出大問題。用AtomicStampedReference就能感知到版本的變更。不過實(shí)踐中大部分 ABA 場景其實(shí)影響不大比如店鋪庫存這種最終還是看當(dāng)前值的地方它更關(guān)心的是即時(shí)狀態(tài)。這點(diǎn)你主動(dòng)說出來反而會(huì)顯得有真實(shí)項(xiàng)目判斷力。3.3 線程池的核心參數(shù)與真實(shí)調(diào)優(yōu)場景線程池面試題問得極其高頻核心就是那七個(gè)參數(shù)corePoolSize、maximumPoolSize、keepAliveTime、workQueue、threadFactory、handler還有一個(gè) BlockingQueue 的實(shí)現(xiàn)選擇。很多人把參數(shù)背得很熟但一追問“你這幾個(gè)參數(shù)在線上怎么定的”就卡住了。先理一遍流程提交任務(wù)后當(dāng)前線程數(shù)小于核心線程數(shù)就創(chuàng)建新線程執(zhí)行超過核心線程數(shù)任務(wù)先進(jìn)入隊(duì)列隊(duì)列也滿了繼續(xù)創(chuàng)建線程直到最大線程數(shù)再滿執(zhí)行拒絕策略。這里最容易被誤解的是“corePoolSize 滿了之后是擴(kuò)容線程而不是等隊(duì)列滿直接拒”。線程數(shù)從 core 擴(kuò)展到 max 的前提是隊(duì)列已滿。拒絕策略有四種AbortPolicy是直接拋異常CallerRunsPolicy是讓提交任務(wù)的線程自己跑DiscardPolicy是靜默丟棄DiscardOldestPolicy是丟棄隊(duì)列里最老的任務(wù)。實(shí)際項(xiàng)目里我一般推薦CallerRunsPolicy它不會(huì)丟任務(wù)同時(shí)也天然提供了一種背壓機(jī)制當(dāng)線程池飽和時(shí)調(diào)用方線程被迫執(zhí)行任務(wù)就自然放慢了提交速度。參數(shù)怎么定要看任務(wù)是 CPU 密集型還是 IO 密集型。CPU 密集型期望核心線程數(shù)接近 CPU 核數(shù)通常是N1IO 密集型因?yàn)榇蟛糠謺r(shí)間在等待網(wǎng)絡(luò)或磁盤線程數(shù)可以多一點(diǎn)常用公式是N * (1 等待時(shí)間 / 計(jì)算時(shí)間)。我曾經(jīng)調(diào)過一個(gè)報(bào)表導(dǎo)出服務(wù)壓測時(shí)線程數(shù)從 20 加到 50吞吐量不升反降因?yàn)榇罅烤€程同時(shí)爭搶數(shù)據(jù)庫連接連接池先成了瓶頸。后來把思路反過來先定數(shù)據(jù)庫連接池上限再反推線程池大小同時(shí)把導(dǎo)出任務(wù)拆成更細(xì)的批次放入隊(duì)列最終吞吐量反而翻倍。面試?yán)锬苤v清楚這類權(quán)衡比單純背公式有價(jià)值得多。4. Spring 與 Spring Boot框架題背后的設(shè)計(jì)思想4.1 Bean 的生命周期與三級(jí)緩存解決循環(huán)依賴Spring 題目現(xiàn)在普遍向源碼靠攏。第一個(gè)高頻題“Spring 中 Bean 的生命周期是什么”簡單概括就是實(shí)例化前階段BeanPostProcessor 的初始化前置處理、實(shí)例化、屬性填充、初始化InitializingBean、init-method、使用、銷毀。但最好把這個(gè)流程掛到具體接口上去理解。比如BeanPostProcessor的postProcessBeforeInitialization和postProcessAfterInitialization分別會(huì)在初始化前后被調(diào)用AOP 的代理對象就是在postProcessAfterInitialization這個(gè)階段生成的。Autowired依賴注入發(fā)生在屬性填充階段而PostConstruct注解是在屬性填充完成之后才執(zhí)行。理解了這個(gè)順序你就明白了為什么在構(gòu)造方法里直接使用Autowired屬性會(huì)拿到 null因?yàn)闃?gòu)造方法執(zhí)行時(shí)機(jī)早于屬性填充。循環(huán)依賴問題也非常經(jīng)典“Spring 怎么解決循環(huán)依賴”注意Spring 解決的是單例 Bean 的 setter 注入循環(huán)依賴構(gòu)造器注入的循環(huán)依賴它解決不了會(huì)直接拋BeanCurrentlyInCreationException。Spring 的做法是三級(jí)緩存第一級(jí)是singletonObjects存放完整的單例 Bean第二級(jí)是earlySingletonObjects存放提前暴露的、還沒完成屬性填充的半成品對象第三級(jí)是singletonFactories存放 ObjectFactory。為什么需要第三級(jí)而不是直接提前創(chuàng)建完整對象因?yàn)榇蟛糠?Bean 在創(chuàng)建后期會(huì)被動(dòng)態(tài)代理如果二級(jí)緩存直接放原始對象后續(xù)代理對象就沒有機(jī)會(huì)替換了。三級(jí)緩存中存的是 ObjectFactory在真正暴露的時(shí)候才決定是返回原始對象還是代理對象這樣既保證了單例語義又給 AOP 留了口子。答出這一層面試官通常會(huì)比較滿意。4.2 AOP 的底層代理機(jī)制與失效場景AOP 在 Spring 家族里的實(shí)踐非常廣泛從聲明式事務(wù)到日志切面、權(quán)限控制再到Async底層都離不開動(dòng)態(tài)代理。高頻問題就是“JDK 動(dòng)態(tài)代理和 CGLIB 有什么區(qū)別Spring 里會(huì)怎么選”JDK 動(dòng)態(tài)代理基于接口通過Proxy.newProxyInstance生成一個(gè)實(shí)現(xiàn)同樣接口的代理類調(diào)用方法時(shí)通過InvocationHandler轉(zhuǎn)發(fā)CGLIB 則通過繼承目標(biāo)類生成子類重寫目標(biāo)方法。JDK 自帶的代理要求目標(biāo)類必須有接口而 CGLIB 可以代理沒有接口的類。Spring Boot 2.x 之后默認(rèn)使用的是 CGLIB也就是通過proxyTargetClasstrue因?yàn)楝F(xiàn)在很多業(yè)務(wù)類根本不設(shè)計(jì)接口直接 CGLIB 更省心。但如果目標(biāo)方法是 final 的或者類是 final 的CGLIB 也代理不了因?yàn)樽宇悷o法重寫 final 方法。AOP 失效的經(jīng)典場景是什么最典型的就是同類內(nèi)部方法調(diào)用。Spring 的代理只在從外部調(diào)用 Bean 的方法時(shí)生效如果 Bean 內(nèi)部一個(gè)方法調(diào)用另一個(gè)帶Transactional的方法走的是this引用沒有經(jīng)過代理對象事務(wù)就失效了。解決辦法有三個(gè)注入自身代理、拆到另一個(gè) Bean 里、使用AopContext.currentProxy()。這些細(xì)節(jié)在面試?yán)飳儆凇按鹜暝碇笾鲃?dòng)補(bǔ)充的提分點(diǎn)”。還有個(gè)容易混淆的點(diǎn)Spring 的事務(wù)和Async用的是同一個(gè)代理機(jī)制所以很多Async失效的問題根因和事務(wù)失效是一模一樣的。4.3 Spring 事務(wù)失效的八大典型場景“Spring 事務(wù)在什么情況下會(huì)失效”這是大廠面試官比較愛出的“場景題”因?yàn)闃I(yè)務(wù)項(xiàng)目里事務(wù)踩坑太常見了。我總結(jié)下來有八個(gè)典型場景。第一方法不是 public 的Spring 默認(rèn)用 CGLIB 代理代理只能增強(qiáng) public 方法非 public 方法的事務(wù)注解不生效。第二同類內(nèi)部調(diào)用也就是前面說的不走代理。第三異常被 catch 住吞掉了事務(wù)感知不到異常自然無法回滾。第四拋出的異常類型不是 RuntimeException而是 checked Exception比如IOExceptionSpring 默認(rèn)只對 RuntimeException 回滾checked 異常不會(huì)觸發(fā)回滾除非在Transactional里顯式指定rollbackFor。第五數(shù)據(jù)庫引擎不支持事務(wù)比如 MySQL 用了 MyISAM 表。第六多線程調(diào)用一個(gè)方法內(nèi)開啟子線程去執(zhí)行另一個(gè)事務(wù)方法因?yàn)槭聞?wù)和線程綁定子線程里的事務(wù)不會(huì)和主線程合并而且子線程拋異常也不會(huì)回滾主線程。第七事務(wù)方法里使用this調(diào)用切面相關(guān)的內(nèi)部方法。第八類沒有被 Spring 管理也就是忘了加Service之類的注解。每個(gè)場景背后其實(shí)都指向同一個(gè)核心理解Spring 事務(wù)的本質(zhì)是 AOP本質(zhì)是通過代理攔截目標(biāo)方法在方法執(zhí)行前開啟事務(wù)、在方法返回或拋出異常時(shí)提交或回滾。把這個(gè)本質(zhì)講清楚八個(gè)場景根本不用背自己就能推導(dǎo)出來。5. MySQL 與 Redis數(shù)據(jù)層的進(jìn)階追問5.1 索引為什么選 B 樹什么時(shí)候索引會(huì)失效MySQL 的索引是必考內(nèi)容而且角度越來越刁鉆。最基本的題目是“InnoDB 的索引為什么用 B 樹而不用 B 樹或者紅黑樹”B 樹相比 B 樹的優(yōu)勢是數(shù)據(jù)只存儲(chǔ)在葉子節(jié)點(diǎn)內(nèi)部節(jié)點(diǎn)只存鍵值所以單頁可以容納更多索引項(xiàng)樹的層級(jí)更矮。三層 B 樹大概可以存儲(chǔ)千萬級(jí)別到億級(jí)別的數(shù)據(jù)量加上葉子節(jié)點(diǎn)之間有鏈表連接做范圍查詢非常高效。紅黑樹是二叉樹高度遠(yuǎn)高于 B 樹磁盤 IO 次數(shù)多完全不適合數(shù)據(jù)庫這種以磁盤塊為單位的訪問模式。哈希索引雖然能 O(1) 做等值查詢但沒法做范圍查詢也無法利用最左前綴。這是從數(shù)據(jù)結(jié)構(gòu)特性去理解 MySQL 選型的核心邏輯。接著就會(huì)被問二級(jí)索引和回表。InnoDB 是聚簇索引主鍵索引的葉子節(jié)點(diǎn)直接存整行數(shù)據(jù)二級(jí)索引的葉子節(jié)點(diǎn)存的是主鍵值。用二級(jí)索引查詢時(shí)先找到主鍵再回聚簇索引查一次這個(gè)過程叫回表。如果查詢的列正好全部在二級(jí)索引里就形成了覆蓋索引不需要回表性能會(huì)好很多。這就是為什么查詢建議只 select 必要列而不是無腦 select *因?yàn)橐坏纤饕獾牧懈采w索引就用不上了。索引失效的場景也是必背清單對索引列使用函數(shù)或者運(yùn)算發(fā)生隱式類型轉(zhuǎn)換比如索引列是字符串查詢條件卻用了數(shù)字使用模糊匹配且通配符在前面LIKE %abc無法走索引LIKE abc%可以使用OR連接非索引列聯(lián)合索引不滿足最左前綴規(guī)則。這些規(guī)則背下來是基礎(chǔ)但更關(guān)鍵的是能從“索引本身就是一種有序結(jié)構(gòu)”的角度去理解為什么失效。比如對索引列做運(yùn)算本質(zhì)上是改變了索引列的值原有排序無法再用自然就失效了。5.2 MySQL 的鎖機(jī)制與事務(wù)隔離級(jí)別MySQL 并發(fā)控制的相關(guān)問題核心圍繞事務(wù)隔離級(jí)別和鎖。事務(wù)的四大特性 ACID 人人都能背關(guān)鍵是隔離級(jí)別。MySQL 默認(rèn)的隔離級(jí)別是REPEATABLE READ也就是可重復(fù)讀。它通過多版本并發(fā)控制MVCC實(shí)現(xiàn)快照讀同時(shí)用next-key lock解決幻讀問題。這里的 next-key lock 是記錄鎖和間隙鎖的組合它鎖定的不只是某一行還包括這行之前的間隙這樣別的事務(wù)就無法在間隙里插入新數(shù)據(jù)。理解了這一點(diǎn)就能解釋為什么在可重復(fù)讀級(jí)別下某些范圍查詢會(huì)把不相干的記錄也鎖住從而可能引發(fā)死鎖。面試時(shí)一個(gè)更高頻的追問是“READ COMMITTED和REPEATABLE READ的區(qū)別是什么”簡單說前者每次讀取都生成新的快照所以同一事務(wù)內(nèi)兩次查詢結(jié)果可能不同后者在事務(wù)開始時(shí)就生成快照后續(xù)讀的是同一個(gè)快照所以能重復(fù)讀。但要注意可重復(fù)讀的快照讀并不能完全避免幻影讀下的寫沖突需要結(jié)合 next-key lock 才能做完整防護(hù)。這也是為什么很多人說 MySQL 在默認(rèn)隔離級(jí)別下其實(shí)已經(jīng)基本做到了類似串行化隔離級(jí)別下才有的防幻讀效果。關(guān)于死鎖面試官很喜歡讓候選人現(xiàn)場分析。比如兩條 update 語句以相反順序鎖定兩行數(shù)據(jù)就可能形成互相等待。排查死鎖的常規(guī)動(dòng)作是執(zhí)行SHOW ENGINE INNODB STATUS查看 LATEST DETECTED DEADLOCK 部分找到持鎖的事務(wù)和等待鎖的事務(wù)。業(yè)務(wù)上規(guī)避死鎖的一個(gè)重要思路是讓所有事務(wù)以固定的順序訪問表和行。5.3 Redis 緩存穿透、擊穿、雪崩的應(yīng)對方案Redis 相關(guān)的場景題最經(jīng)典的就是緩存三大問題。緩存穿透是查詢一個(gè)根本不存在的 key請求打到數(shù)據(jù)庫上如果這種請求量很大數(shù)據(jù)庫壓力就會(huì)異常。解決思路是緩存空值把不存在的 key 也緩存一下但要設(shè)置較短的過期時(shí)間更好的是用布隆過濾器在緩存前面加一道判斷把明顯不存在的 key 直接攔截掉。注意布隆過濾器有誤判率它會(huì)告訴你“一定不存在”和“可能存在”誤判不會(huì)漏掉真實(shí)存在的 key只會(huì)把極少數(shù)不存在的 key 放過去這在緩存場景下是可接受的。緩存擊穿是某個(gè)熱點(diǎn) key 在過期瞬間大量并發(fā)請求同時(shí)打到數(shù)據(jù)庫。處理辦法有三個(gè)互斥鎖也就是只讓一個(gè)請求去重建緩存其他請求等待邏輯過期把 value 里塞一個(gè)過期時(shí)間字段異步線程去更新緩存請求先拿舊值返回永不過期加后臺(tái)定時(shí)刷新?；コ怄i實(shí)現(xiàn)簡單但存在串行化問題邏輯過期能做到最終一致且不阻塞請求但對業(yè)務(wù)代碼有侵入。緩存雪崩是大量 key 同時(shí)過期或者 Redis 實(shí)例宕機(jī)導(dǎo)致請求全部落到數(shù)據(jù)庫。應(yīng)對策略包括過期時(shí)間加一個(gè)隨機(jī)值避免同一時(shí)刻集體過期用多級(jí)緩存本地緩存加分布式緩存Redis 高可用部署加上熔斷降級(jí)策略。面試官通常會(huì)追問“如果 Redis 掛了你怎么辦”這時(shí)候不要只答“等它恢復(fù)”而要把兜底方案講出來本地緩存臨時(shí)頂上、對非核心接口做降級(jí)、數(shù)據(jù)庫提前做讀寫分離擴(kuò)容。6. 分布式與場景題沒有標(biāo)準(zhǔn)答案的加分項(xiàng)6.1 分布式鎖Redis 鎖、ZooKeeper 鎖與 Redlock 之爭到了這個(gè)層面面試題逐漸變成“開放題”。第一個(gè)典型的開放問題是“你在項(xiàng)目里怎么設(shè)計(jì)一個(gè)分布式鎖”如果用的是 Redis最簡單的方案是SET key value EX seconds NX只有鍵不存在時(shí)才能設(shè)置成功過期時(shí)間保證鎖不會(huì)永久持有。但這里面有幾個(gè)坑。第一個(gè)坑是鎖的 value 必須帶上一個(gè)唯一標(biāo)識(shí)比如 UUID釋放鎖時(shí)要先比較 value 再刪除否則可能出現(xiàn)線程 A 的鎖到期自動(dòng)釋放線程 B 拿到了新鎖然后 A 又去把 B 的鎖刪掉的情況。第二個(gè)坑是主從切換時(shí)的丟鎖問題Redis 主節(jié)點(diǎn)宕機(jī)后從節(jié)點(diǎn)頂上如果鎖還沒來得及同步到從節(jié)點(diǎn)鎖就丟了。Redlock 算法試圖通過向多個(gè)獨(dú)立 Redis 節(jié)點(diǎn)加鎖來解決這個(gè)問題但它在極端情況下仍有爭議比如發(fā)生時(shí)鐘跳躍時(shí)。面試時(shí)主動(dòng)講出 Redlock 的適用場景和爭議點(diǎn)會(huì)讓面試官覺得你真的在生產(chǎn)環(huán)境里思考過。如果用 ZooKeeper 做分布式鎖常見做法是創(chuàng)建臨時(shí)順序節(jié)點(diǎn)每個(gè)客戶端注冊后得到一個(gè)序號(hào)只有序號(hào)最小的持有鎖其他客戶端監(jiān)聽前一個(gè)節(jié)點(diǎn)。臨時(shí)節(jié)點(diǎn)的好處是客戶端宕機(jī)后節(jié)點(diǎn)自動(dòng)消失不會(huì)出現(xiàn) Redis 鎖那種“死鎖后只能等過期”的問題。但 ZooKeeper 鎖的性能不如 Redis而且每次加鎖都要多次網(wǎng)絡(luò)交互。實(shí)際選型邏輯是要求高可靠性和自動(dòng)釋放就選 ZooKeeper追求性能和簡單性就選 Redis。這個(gè)問題沒有唯一答案你把自己項(xiàng)目的訪問量、可用性要求、已有基礎(chǔ)設(shè)施說清楚就是完整的回答。6.2 接口冪等性與重復(fù)提交的處理“怎么保證接口的冪等性”是分布式場景的?？?。面試題包裝通常是“用戶快速點(diǎn)了兩次提交后端重復(fù)扣款了怎么避免”。冪等性設(shè)計(jì)的核心思想是讓一次和多次請求的效果相同。最簡單也最可靠的方法是在數(shù)據(jù)庫層面加唯一約束比如訂單號(hào)唯一、支付流水號(hào)唯一。第一次插入成功第二次插入會(huì)因?yàn)槲ㄒ绘I沖突而失敗業(yè)務(wù)代碼里捕獲這個(gè)沖突返回“處理中”或者“已成功”即可。對于更新場景可以用樂觀鎖表里加一個(gè)版本號(hào)update 時(shí)帶上version ?條件更新成功后版本號(hào)加一更新行數(shù)為 0 就說明版本不匹配直接丟棄該次請求。還有一種思路是使用狀態(tài)機(jī)。比如支付單的狀態(tài)從“待支付”到“支付中”再到“已支付”是一個(gè)不可逆的過程業(yè)務(wù)代碼里通過update ... where status 待支付這樣的條件更新來保證同一狀態(tài)只能被成功推進(jìn)一次。這種方案的優(yōu)點(diǎn)是語義清晰缺點(diǎn)是業(yè)務(wù)代碼里到處都要寫狀態(tài)判斷侵入性強(qiáng)。面試?yán)锬阒灰v清楚場景匹配哪種方案比如“下單用唯一鍵扣庫存用樂觀鎖長流程用狀態(tài)機(jī)”就比只背一個(gè)方案要出彩。6.3 消息隊(duì)列的可靠性不丟、不重、有序消息隊(duì)列一定是分布式簡歷里的高頻組件。高頻題是“怎么保證消息不丟失”回答這個(gè)問題要分三段來拆。生產(chǎn)端使用同步發(fā)送并等待 Broker 確認(rèn)或者開啟事務(wù)消息、確認(rèn)回調(diào)保證消息真正到達(dá) BrokerBroker 端開啟持久化把消息刷到磁盤并且對應(yīng)的隊(duì)列設(shè)置為持久化隊(duì)列消費(fèi)端關(guān)閉自動(dòng) ack改成手動(dòng) ack處理成功后再確認(rèn)。只要三段每一段都有確認(rèn)機(jī)制消息就能基本做到不丟。注意消息隊(duì)列的不丟是有條件的不丟不同中間件默認(rèn)配置不一樣比如 Kafka 的配置要關(guān)注acks、min.insync.replicas和enable.auto.commit三個(gè)參數(shù)?！霸趺幢ＷC不重復(fù)消費(fèi)”這才是更難的問題。因?yàn)榫W(wǎng)絡(luò)重試、消費(fèi)者宕機(jī)再恢復(fù)都會(huì)導(dǎo)致同一消息被投遞多次。消息中間件只能保證至少一次語義無法保證剛好一次所以業(yè)務(wù)側(cè)必須做冪等這又繞回了上一個(gè)話題數(shù)據(jù)庫唯一鍵、Redis setnx、狀態(tài)機(jī)都天然可以用來做消費(fèi)冪等?！跋⒃趺幢ＷC順序性”Kafka 的答案是分區(qū)有序同一業(yè)務(wù) key 的消息發(fā)到同一個(gè)分區(qū)消費(fèi)者在分區(qū)內(nèi)順序處理。但一旦有多個(gè)消費(fèi)者并發(fā)消費(fèi)同一個(gè)分區(qū)順序就會(huì)亂。所以實(shí)踐中通常還要配合“單分區(qū)單消費(fèi)者”或者把并發(fā)度收斂再在業(yè)務(wù)側(cè)用狀態(tài)機(jī)做兜底。這三類問題串起來答能明顯增加面試的完整度。7. 面試現(xiàn)場加減分項(xiàng)聊幾個(gè)實(shí)操心得7.1 答題節(jié)奏與“主動(dòng)引導(dǎo)”最后再分享幾個(gè)我既作為面試官、也作為被面試者總結(jié)出來的實(shí)操體會(huì)。第一答題要學(xué)會(huì)分層。面試官問一個(gè)概念先給一句話結(jié)論再展開細(xì)節(jié)不要上來就倒一大堆。比如問“HashMap 和 ConcurrentHashMap 有什么區(qū)別”先說“線程安全的差異和底層實(shí)現(xiàn)不同”再分別展開。提綱挈領(lǐng)的答法讓面試官可以隨時(shí)打斷你或者沿著你的話問下去節(jié)奏更可控。第二主動(dòng)暴露“邊界”。說完了常規(guī)實(shí)現(xiàn)補(bǔ)一句“但是這個(gè)方案在某某場景下有局限”面試官通常會(huì)被帶著往你準(zhǔn)備好的方向問。比如聊 Redis 分布式鎖你主動(dòng)提主從切換丟鎖問題話題就很自然滑向 Redlock 和 CAP這些都是你能提前準(zhǔn)備的。千萬不要只等面試官出招那樣很容易被問到知識(shí)盲區(qū)。第三不會(huì)的題要表現(xiàn)推導(dǎo)過程。大廠面試官其實(shí)不是非要你每道題都答對他們更關(guān)注你面對不確定問題的反應(yīng)。遇到不會(huì)的題先把已知的部分拆解出來再嘗試類比到熟悉的東西上。比如讓你說一個(gè)沒接觸過的中間件的實(shí)現(xiàn)原理你可以從“它解決什么問題、有什么類似物、數(shù)據(jù)怎么流轉(zhuǎn)”三個(gè)角度推。哪怕推得不夠準(zhǔn)確也比沉默或瞎編強(qiáng)。7.2 簡歷和項(xiàng)目經(jīng)驗(yàn)的技術(shù)錨點(diǎn)還有一個(gè)容易被低估的環(huán)節(jié)項(xiàng)目描述里提到的每個(gè)技術(shù)名詞都要準(zhǔn)備好被追問。寫“用了 Redis 緩存”就要準(zhǔn)備緩存穿透、擊穿、雪崩、緩存一致性這幾個(gè)問題寫“用消息隊(duì)列做了異步解耦”就要準(zhǔn)備可靠性、順序性、積壓處理這些問題。項(xiàng)目里用到了什么技術(shù)面試官默認(rèn)你會(huì)往深了聊所以不要在簡歷上堆不認(rèn)識(shí)的名詞。我建議把項(xiàng)目經(jīng)驗(yàn)按“背景、方案、難點(diǎn)、結(jié)果”四段式準(zhǔn)備其中“難點(diǎn)”是重中之重。難點(diǎn)最好是那種能在技術(shù)層面體現(xiàn)出取舍的問題比如“訂單量上漲后數(shù)據(jù)庫查詢變慢你是怎么優(yōu)化的”。這種問題既考察技術(shù)寬度也考察你是不是真的參與了這個(gè)項(xiàng)目。把優(yōu)化前后的數(shù)據(jù)對比也準(zhǔn)備好有數(shù)據(jù)支撐的回答說服力完全不一樣。準(zhǔn)備面試本質(zhì)上就是在整理自己的知識(shí)體系。刷題只是引子真正重要的還是把每個(gè)問題的“為什么”想清楚。我自己的體會(huì)是把上面這幾條線吃透不管面試題拿到的是哪套組合都能找到對應(yīng)的思考路徑。把心態(tài)放穩(wěn)把基礎(chǔ)夯實(shí)金三銀四的機(jī)會(huì)自然會(huì)落到有準(zhǔn)備的人手里。