1. 內(nèi)容整體設(shè)計與選題思路先解釋一下“八股Day02”這個標(biāo)題?，F(xiàn)在很多技術(shù)社區(qū)和求職群里“八股”這個詞已經(jīng)被重新定義了——它從早年的貶義詞變成了求職者自嘲式的統(tǒng)稱。所謂“八股”就是面試中最?？嫉?、有標(biāo)準(zhǔn)答案的、背下來就能拿分的那批知識點。比如Java的HashMap原理、并發(fā)編程的volatile關(guān)鍵字、MySQL的索引結(jié)構(gòu)這些都屬于典型的八股。而“Day02”意味著這是一套系列整理中的第二天第一天通常是環(huán)境準(zhǔn)備和總綱第二天就該進(jìn)入核心知識模塊了。我之所以專門寫這個系列是因為這幾年觀察到一個很普遍的現(xiàn)象很多人的技術(shù)底子并不差項目也做得挺扎實但一到面試就吃虧。吃虧的原因往往不是不會而是答不到點子上——要么東扯西扯繞遠(yuǎn)了要么三言兩語把面試官想聽的細(xì)節(jié)全跳過了。八股文復(fù)習(xí)看起來枯燥但它其實是在幫你建立一套“面試官視角的答題框架”。你掌握了這套框架哪怕遇到?jīng)]準(zhǔn)備過的題也能順著框架往正確的方向去答。Day02這篇我打算聚焦在三個最核心的模塊Java集合框架、并發(fā)編程基礎(chǔ)、MySQL索引與事務(wù)。為什么選這三個因為它們幾乎是所有Java后端崗位面試中出現(xiàn)頻率最高的區(qū)域。我統(tǒng)計過近兩年幾十場大中小廠的面試反饋這三個模塊合計能占到技術(shù)面問題的四成以上。如果你時間有限只能集中精力復(fù)習(xí)一部分內(nèi)容從這三塊下手是性價比最高的選擇。這篇內(nèi)容適合誰兩類人。第一類是正在準(zhǔn)備求職面試的開發(fā)者不管是應(yīng)屆生還是跳槽選手這套內(nèi)容可以直接拿來背、拿來練第二類是剛工作不久、想系統(tǒng)補(bǔ)一下基礎(chǔ)功底的初級工程師你會發(fā)現(xiàn)很多平時寫代碼時“模模糊糊知道”的東西在這篇文章里能徹底弄明白。2. 核心細(xì)節(jié)拆解這三個模塊到底在考什么2.1 Java集合從HashMap到源碼級理解集合這塊面試官最愛考的其實就是HashMap。我參加過很多場面試幾乎每場都會問到HashMap。但很多人對HashMap的理解就停留在“數(shù)組加鏈表”這個層面這遠(yuǎn)遠(yuǎn)不夠。先補(bǔ)基礎(chǔ)HashMap的底層結(jié)構(gòu)是數(shù)組每個數(shù)組元素是一個桶bucket。當(dāng)多個key的哈希值經(jīng)過擾動函數(shù)計算后落到同一個桶時就用鏈表來存儲沖突的元素。當(dāng)鏈表長度超過閾值默認(rèn)是8且數(shù)組長度大于等于64時鏈表會轉(zhuǎn)換成紅黑樹目的是把查詢時間復(fù)雜度從O(n)降為O(log n)。但面試官真正想聽的往往不是這個結(jié)論而是你懂不懂“為什么要這樣設(shè)計”。比如為什么鏈表轉(zhuǎn)紅黑樹的閾值是8這里有個統(tǒng)計學(xué)背景——HashMap的作者在源碼注釋里引用過泊松分布的計算結(jié)果在負(fù)載因子0.75、隨機(jī)哈希的情況下鏈表長度達(dá)到8的概率大約是千萬分之六所以8這個閾值是一個兼顧空間和時間的平衡點。再看擴(kuò)容機(jī)制。HashMap的默認(rèn)初始容量是16負(fù)載因子是0.75也就是說當(dāng)元素個數(shù)超過16×0.7512時就會觸發(fā)擴(kuò)容。擴(kuò)容時新容量是舊容量的兩倍并且所有元素需要重新計算哈希并分配到新數(shù)組中。這里面有個容易被忽略的細(xì)節(jié)JDK 1.8之后擴(kuò)容時不需要像1.7那樣每個元素都重新計算hash值而是通過判斷元素原h(huán)ash值的新增bit位是0還是1把原鏈表拆成lo鏈表和hi鏈表這樣既避免了死循環(huán)問題也提高了擴(kuò)容效率。這塊內(nèi)容我強(qiáng)烈建議你親自打開源碼讀一遍重點看三個方法putVal、resize、treeifyBin。讀源碼不是為了背代碼而是為了理解設(shè)計者的思路。你會發(fā)現(xiàn)很多面試題其實就是從源碼里“翻譯”過來的。2.2 并發(fā)編程volatile、synchronized與鎖升級并發(fā)編程是另一個面試重災(zāi)區(qū)。很多人能說出volatile的兩個特性——可見性和有序性但問到“它為什么不保證原子性”就卡殼了。先說可見性。volatile修飾的變量每次被線程訪問時都會強(qiáng)制從主內(nèi)存重新讀取每次修改后也會立刻寫回主內(nèi)存。這就保證了其他線程能夠及時看到這個變量的最新值。但注意這并不代表它是線程安全的——比如count這種操作本質(zhì)上是“讀-改-寫”三步volatile只能保證每一步的可見性不能保證這三步作為一個整體不被其他線程打斷。這里我推薦用一個生活化類比來理解volatile就像是在辦公室里貼了一張公告板。你在公告板上寫了最新消息所有同事都能第一時間看到但如果有兩個同事同時想改公告板上的同一個數(shù)字他們的動作之間沒有協(xié)調(diào)最后寫上去的可能是其中一個人覆蓋了另一個人的結(jié)果。再說synchronized。JDK 1.6之后synchronized經(jīng)歷了大規(guī)模的優(yōu)化引入了偏向鎖、輕量級鎖、重量級鎖的升級過程。很多人以為synchronized一上來就是重量級鎖這是誤解。實際上無競爭時是偏向鎖有輕微競爭時升級為輕量級鎖通過CAS自旋自旋失敗或競爭激烈時才升級為重量級鎖。這個升級過程是單向的鎖只能升級不能降級。面試中常見的追問是既然有了synchronized為什么還要有Lock答案的核心是Lock提供了更靈活的鎖操作比如可中斷獲取鎖、可超時獲取鎖、公平鎖/非公平鎖切換、多個條件隊列Condition等。而synchronized在Java 6優(yōu)化之后性能上其實和Lock差距不大選型時更多是看需求而不是單純看性能。2.3 MySQL索引失效場景與事務(wù)隔離級別MySQL這塊問得最多的兩個方向索引為什么能加速查詢、事務(wù)隔離級別是怎么回事。關(guān)于索引核心要先理解B樹。B樹相比B樹有兩個關(guān)鍵差異非葉子節(jié)點不存儲數(shù)據(jù)只存儲索引鍵葉子節(jié)點之間通過鏈表相連。這意味著B樹的查詢路徑更短且穩(wěn)定所有查詢都要走到葉子節(jié)點同時范圍查詢通過葉子節(jié)點的鏈表可以順序掃描效率極高。然后是索引失效問題。很多人在實際工作中寫過慢查詢排查到最后發(fā)現(xiàn)是索引沒走。常見的索引失效場景包括對索引列使用函數(shù)或表達(dá)式計算、隱式類型轉(zhuǎn)換導(dǎo)致無法匹配索引、like查詢以通配符開頭、使用or連接非索引列等。我記得有一次幫同事排查一個線上慢查詢SQL很簡單但執(zhí)行時間要300多毫秒。一查執(zhí)行計劃發(fā)現(xiàn)明明有索引卻沒走。問題就出在查詢條件里對索引列做了date(create_time) 2024-01-01這種函數(shù)操作。改成create_time 2024-01-01 00:00:00 AND create_time 2024-01-02 00:00:00之后查詢秒回。這是一個非常經(jīng)典的細(xì)節(jié)坑。事務(wù)隔離級別這塊MySQL默認(rèn)是REPEATABLE READ可重復(fù)讀這也是它和很多其他數(shù)據(jù)庫不同的地方。四種隔離級別要能回答清楚各自解決了什么問題READ UNCOMMITTED讀未提交會有臟讀、不可重復(fù)讀、幻讀READ COMMITTED讀已提交解決了臟讀但還有不可重復(fù)讀和幻讀REPEATABLE READ解決了臟讀和不可重復(fù)讀但還有幻讀InnoDB通過間隙鎖和MVCC在特定場景下能避免幻讀SERIALIZABLE則通過鎖串行化執(zhí)行徹底解決了幻讀但并發(fā)性能很差。MYSQL的InnoDB在REPEATABLE READ級別下通過MVCC快照讀和當(dāng)前讀加鎖的組合實際上已經(jīng)能在大多數(shù)場景下避免幻讀這也是為什么MySQL敢把默認(rèn)級別設(shè)為REPEATABLE READ的原因。3. 實操要點怎么把這些知識點變成自己的3.1 源碼閱讀的正確打開方式很多人一聽讀源碼就頭大其實方法不對才是最大的障礙。我建議不要從頭到尾讀而是“帶著問題讀”。還是以HashMap為例你帶著“put一個key到底經(jīng)歷了哪些步驟”這個問題按以下路徑去讀定位put方法看到它調(diào)用了putVal。putVal里第一步看table是否為空空則調(diào)用resize()初始化。然后通過(n - 1) hash計算下標(biāo)這里n是數(shù)組長度hash是擾動后的哈希值。判斷該下標(biāo)處是否有節(jié)點沒有就直接newNode插入。有節(jié)點則判斷是鏈表還是紅黑樹分別走不同的插入邏輯。插入完成后檢查size threshold是則擴(kuò)容。這六步走下來你對HashMap整個寫入流程就有了清晰的心智模型。面試時你能把這條鏈路講清楚比干巴巴背十個結(jié)論管用得多。3.2 并發(fā)編程的驗證實驗并發(fā)這塊光看理論不夠扎實我強(qiáng)烈建議動手寫兩個小實驗來驗證。第一個實驗起兩個線程一個線程不停修改一個普通int變量另一個線程循環(huán)讀取這個變量。你會發(fā)現(xiàn)在沒有volatile的情況下第二個線程可能永遠(yuǎn)看不到第一個線程的修改。這正是Java內(nèi)存模型的具體體現(xiàn)。加上volatile后再跑一次現(xiàn)象就變了。親手跑過這個實驗?zāi)銓Α翱梢娦浴钡睦斫饩偷轿涣?。第二個實驗用synchronized修飾一個方法創(chuàng)建多個線程并發(fā)調(diào)用它然后在代碼里打印線程名。你能直觀看到同一時間只有一個線程能進(jìn)入方法。然后再試試去掉synchronized看看輸出結(jié)果如何變得混亂。這個實驗雖然簡單但能幫你建立“鎖就是串行化的通行證”這個認(rèn)知。3.3 MySQL索引的驗證建議索引這塊用EXPLAIN看執(zhí)行計劃是最直接的驗證手段。我給你一個練習(xí)清單創(chuàng)建一個包含name、age、create_time三個字段的表加上(name, age)的聯(lián)合索引。分別執(zhí)行WHERE name 張三、WHERE name 張三 AND age 20、WHERE age 20三條SQL觀察key和key_len字段。再試試WHERE LEFT(name, 1) 張看看索引是否失效。通過這幾條SQL你能直觀理解最左前綴原則、覆蓋索引的概念以及函數(shù)操作對索引的破壞。實操過一遍比看十篇文章的印象都深。4. 常見問題與排查技巧實錄4.1 HashMap相關(guān)的高頻追問追問一HashMap是線程安全的嗎不是。多線程環(huán)境下如果多個線程同時put可能導(dǎo)致數(shù)據(jù)覆蓋甚至在JDK 1.7中會因擴(kuò)容時的頭插法造成死循環(huán)。JDK 1.8改為尾插法后死循環(huán)問題得到緩解但數(shù)據(jù)丟失和覆蓋問題依然存在。并發(fā)場景應(yīng)該用ConcurrentHashMap。追問二ConcurrentHashMap為什么并發(fā)性能好JDK 1.8的ConcurrentHashMap放棄了分段鎖改用CAS synchronized鎖住數(shù)組中的每個桶。讀操作大多數(shù)情況下不需要加鎖寫操作只鎖當(dāng)前桶的頭節(jié)點所以并發(fā)度非常高。追問三為什么容量總是2的n次冪因為這樣(n - 1) hash就能代替取模運算hash % n而位運算的效率遠(yuǎn)高于取模。同時2的n次冪還能保證擴(kuò)容時元素遷移時只需要判斷高位bit簡化了1.8的高低位拆分邏輯。4.2 synchronized和volatile的經(jīng)典誤區(qū)誤區(qū)一把volatile當(dāng)成線程安全的萬能鑰匙。我見過很多初級工程師在并發(fā)累加的場景用volatile修飾變量以為加了就安全了結(jié)果線上出現(xiàn)了數(shù)據(jù)不準(zhǔn)確的問題。原因很簡單volatile不保證原子性。累加操作需要原子性保證應(yīng)該用AtomicInteger、LongAdder或者干脆加鎖。誤區(qū)二認(rèn)為synchronized性能一定差。這是很久以前的認(rèn)知了。Java 6之后引入鎖升級機(jī)制synchronized在無競爭時開銷非常低。實際性能對比中很多場景下它和ReentrantLock差距很小甚至因為不需要顯式加鎖解鎖代碼更簡潔。選型時應(yīng)按功能需求來性能焦慮反而容易誤導(dǎo)。4.3 MySQL索引面試的避坑清單場景結(jié)果原因正確寫法WHERE date(create_time) 2024-01-01索引失效對索引列用了函數(shù)使用范圍查詢WHERE name 123name是varchar可能失效隱式類型轉(zhuǎn)換傳入正確類型WHERE name LIKE %張%索引失效通配符在前考慮全文索引或改寫WHERE a 1 OR b 2可能失效or兩邊列無法同時走索引拆分成兩個查詢再union這張表建議打印出來貼在工位上寫SQL之前掃一眼能幫你避開大量線上慢查詢。5. 復(fù)習(xí)節(jié)奏與面試話術(shù)設(shè)計5.1 Day02之后該怎么排計劃很多人復(fù)習(xí)的時候有一個致命問題貪多嚼不爛。一天想把所有知識點都過一遍結(jié)果每個都只看了皮毛面試時一問細(xì)節(jié)就露餡。我的建議是Day02的內(nèi)容嚴(yán)格按照“會背、能講、會寫”三層標(biāo)準(zhǔn)來要求自己會背核心結(jié)論能脫口而出比如MySQL默認(rèn)隔離級別、HashMap默認(rèn)容量和負(fù)載因子。能講給你三分鐘你能把這個知識點從是什么、為什么、怎么用三個維度講清楚。會寫關(guān)上筆記手寫一個簡單的生產(chǎn)者消費者模型、或者手寫一個HashMap的put流程偽代碼。這三層是遞進(jìn)的。如果你只能做到第一層面試時面對經(jīng)驗豐富的面試官很容易被連續(xù)追問打崩。至少要做到第二層才算是真正掌握了。5.2 面試回答的“總-分-總”話術(shù)模板回答八股題的時候有個很實用的話術(shù)結(jié)構(gòu)我稱之為“總-分-總”先一句話給出結(jié)論比如“你問我synchronized的鎖升級其實它是一個從偏向鎖到輕量級鎖再到重量級鎖的單向升級過程”。一句話讓面試官知道你會。然后分層展開細(xì)節(jié)把關(guān)鍵條件、參數(shù)和原理講清楚比如鎖升級的觸發(fā)條件、CAS自旋的過程、何時膨脹為重量級鎖。最后用一句話收尾比如“所以你說的性能問題在Java 6之后其實已經(jīng)做了很大的優(yōu)化不同場景下應(yīng)該按需選擇”。這個結(jié)構(gòu)的好處是即便面試官中途打斷你追問其中一層你已經(jīng)展示了整體框架不會被判定為“只會背答案”。5.3 幾個能體現(xiàn)深度的加分細(xì)節(jié)面試中要想從“背八股的人”里脫穎而出可以主動帶出幾個有深度的細(xì)節(jié)。這里我分享三個屢試不爽的加分點第一個是HashMap的泊松分布背景。講到閾值8的時候順帶提一句“源碼注釋里用了泊松分布計算鏈表長度到8的概率大約是千萬分之六”面試官馬上會對你有印象。第二個是synchronized鎖消除和鎖粗化。這兩個是JIT編譯器做的優(yōu)化提到它們能說明你不光知道鎖怎么用還知道JVM層面會怎么處理鎖。第三個是InnoDB為什么默認(rèn)隔離級別是REPEATABLE READ。因為InnoDB用間隙鎖和MVCC在工程上已經(jīng)能避免幻讀所以MySQL選擇這個級別作為默認(rèn)值。這個細(xì)節(jié)能體現(xiàn)出你對數(shù)據(jù)庫設(shè)計取舍的理解而不是死記硬背隔離級別表格。6. 復(fù)盤方法與后續(xù)規(guī)劃八股文復(fù)習(xí)最忌諱的是“背完就忘下次重頭開始”。我建議你建立自己的面試題檔案方法很簡單每復(fù)習(xí)完一個知識點用三句話記錄在筆記里——是什么、為什么、怎么答。然后過一周回來看如果能不看筆記把這三點講出來這個知識點就算真正掌握了。以我個人的經(jīng)驗八股復(fù)習(xí)的最佳節(jié)奏是“三輪循環(huán)法”第一輪快速過一遍全部內(nèi)容不求記住只求有印象第二輪帶著問題深挖盡量閱讀源碼和官方文檔第三輪做輸出練習(xí)用自己的話講給同伴聽或者對著鏡子模擬面試。三輪下來至少能保證你在面試場上不會因為緊張而大腦空白。關(guān)于這個話題我還想多提醒一句八股是敲門磚但不是全部。面試官最終考察的是你的綜合能力——理解力、溝通力、解決問題的思路。八股文背得再熟如果沒有項目實踐經(jīng)驗支撐也很難通過層層深入的技術(shù)面。所以Day02之后別忘了留出時間復(fù)盤自己做過的項目把八股知識點和真實場景結(jié)合起來。這才是這套復(fù)習(xí)計劃最終要幫你達(dá)到的目的。最后再分享一個小技巧整理筆記時不要用“xx是什么”這種標(biāo)題全部改成“如何向面試官解釋xx”的句式。比如“如何向面試官解釋HashMap擴(kuò)容機(jī)制”這樣當(dāng)你在面試現(xiàn)場遇到類似問題時大腦會自動提取你已經(jīng)組織好的語言回答得又快又順。這個小習(xí)慣是我自己用了很多年的方法你也可以試試。