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