從第幾輪面試被問到“String和StringBuilder到底選哪個(gè)”開始我一個(gè)做Java多年的老家伙居然答得支支吾吾那次經(jīng)歷把我徹底打醒了。后來每次幫人模擬面試、每次自己換工作只要遇到值得記的題我都會(huì)往收藏夾里塞一條。幾年下來這份Java開發(fā)面試常見問題的清單越攢越長(zhǎng)也確實(shí)幫好幾個(gè)朋友拿到了心儀的offer如今我還在持續(xù)往里加內(nèi)容。這篇文章就把目前沉淀下來的一些高頻問題和一個(gè)完整的回答思路分享給需要的讀者。不管你是準(zhǔn)備校招、社招還是已經(jīng)在帶新人都可以拿這個(gè)清單來查漏補(bǔ)缺。我不打算寫“標(biāo)準(zhǔn)答案復(fù)制機(jī)”每道題都盡量講清楚面試官為什么要問、從哪個(gè)角度答最容易加分、答完之后還能往哪個(gè)方向擴(kuò)展。建議讀者在看題的時(shí)候先自己說一遍再對(duì)照我的思路這樣效果比單純背題好得多。1. 這份清單為什么值得長(zhǎng)期維護(hù)面試題的本質(zhì)是體檢1.1 面試題不是題庫(kù)是對(duì)知識(shí)體系的掃描Java面試題看起來很多很雜但它們的共同點(diǎn)是每一道高頻題背后都藏著一個(gè)核心知識(shí)點(diǎn)而這個(gè)知識(shí)點(diǎn)通常不是孤立存在的。比如面試官問HashMap的put流程表面上考集合源碼實(shí)際上是在考你對(duì)哈希算法、擴(kuò)容機(jī)制、鏈表轉(zhuǎn)紅黑樹、線程安全隱患這幾個(gè)知識(shí)點(diǎn)的掌握程度。如果你只知道“鏈表長(zhǎng)度超過8轉(zhuǎn)紅黑樹”這句話卻沒看過源碼那遇到追問“為什么是8不是16”的時(shí)候就會(huì)卡住。我自己在維護(hù)這份清單時(shí)發(fā)現(xiàn)面試官的設(shè)計(jì)思路幾乎都是“從一道題開始不斷往下深挖”。他們想看到的不是你會(huì)背概念而是你能圍繞一個(gè)點(diǎn)展開一個(gè)體系。比如從String出發(fā)可以延展到字符串常量池、intern方法、不可變類的設(shè)計(jì)意義再往深就是JVM內(nèi)存區(qū)域里字符串的存放位置。這種層層遞進(jìn)的提問方式就是一次對(duì)知識(shí)體系完整度的檢查。所以我建議讀者不要只盯著題目本身而要把每一道題當(dāng)作一個(gè)入口。做筆記的時(shí)候給每道題畫幾個(gè)“延伸箭頭”把相關(guān)的知識(shí)點(diǎn)串起來。這份清單里我加了大量擴(kuò)展點(diǎn)就是為了讓讀者跟著箭頭走形成自己的網(wǎng)狀知識(shí)結(jié)構(gòu)而不是一條條孤立的記憶線。1.2 我更新這道清單的三條篩選標(biāo)準(zhǔn)并不是所有Java面試題都值得收錄。我給自己定了三條硬標(biāo)準(zhǔn)。第一條是必須高頻或者說在真實(shí)面試中出現(xiàn)次數(shù)足夠多。那些小概率冷門問題我一般不收除非它能引出特別重要的知識(shí)點(diǎn)。第二條是題目必須能帶出兩個(gè)以上的擴(kuò)展知識(shí)純背結(jié)論的題價(jià)值太低比如“final關(guān)鍵字能修飾什么”這種雖然基礎(chǔ)但擴(kuò)展有限我就放在基礎(chǔ)題列表里不會(huì)單獨(dú)長(zhǎng)篇展開。第三條也是最重要的一條答案必須可以被驗(yàn)證。我收的每一題都盡量給出可運(yùn)行代碼、可復(fù)現(xiàn)的場(chǎng)景或者可查證的原理。比如線程池拒絕策略我會(huì)給出一段觸發(fā)AbortPolicy的小示例這樣讀者自己跑一遍就徹底明白了。這個(gè)習(xí)慣幫了我很大忙因?yàn)樗浦颐看握眍}目前都去翻源碼或者寫測(cè)試而不是憑感覺寫“參考答案”一旦憑感覺很容易寫出有誤導(dǎo)性的內(nèi)容。2. Java基礎(chǔ)看著簡(jiǎn)單卻最容易翻車的老牌考點(diǎn)2.1 String、StringBuilder與StringBuffer到底怎么答才加分面試第一輪經(jīng)常從String切入幾乎每個(gè)Java開發(fā)都被問過“String為什么是不可變的”。這里最常見的答法是把String類用final修飾、char數(shù)組是final的、每次修改都會(huì)生成新對(duì)象這幾句背出來。這種回答能拿基礎(chǔ)分但距離加分還有一段距離。更好的回答是分兩步走先講設(shè)計(jì)意圖再講底層實(shí)現(xiàn)細(xì)節(jié)。設(shè)計(jì)意圖上String不可變主要有三個(gè)考慮。第一個(gè)是字符串常量池的復(fù)用如果字符串可變那池里“abc”被改成“abd”所有引用它的變量都跟著變了程序邏輯會(huì)亂套。第二個(gè)是安全性很多地方用String做參數(shù)比如類加載器的名字、數(shù)據(jù)庫(kù)連接地址如果可變就存在被篡改的風(fēng)險(xiǎn)。第三個(gè)是哈希值緩存String的hashCode只用計(jì)算一次然后存下來可變對(duì)象做不了這個(gè)優(yōu)化。至于StringBuilder和StringBuffer的選擇核心點(diǎn)在于線程安全。StringBuffer的方法加了synchronized線程安全但性能差現(xiàn)在很少推薦。StringBuilder不保證線程安全但單線程下性能更好是常規(guī)推薦。面試官往往會(huì)追問“為什么StringBuilder不安全”這時(shí)候可以舉例說明多線程同時(shí)append時(shí)底層數(shù)組擴(kuò)容和值寫入可能交替執(zhí)行導(dǎo)致字符錯(cuò)亂或越界。我在實(shí)際項(xiàng)目里幾乎只在多線程拼接字符串的場(chǎng)景才考慮用別的方案其他情況一律StringBuilder。2.2 與equals以及hashCode之間的“三角債”這個(gè)問題坑過很多人因?yàn)樗婕啊耙帽容^”和“值比較”的根本區(qū)別。對(duì)于基本類型比較的是值本身對(duì)于引用類型比較的是內(nèi)存地址。equals是Object類里的方法默認(rèn)實(shí)現(xiàn)其實(shí)也是用比較地址所以如果不重寫equals兩個(gè)內(nèi)容相同的對(duì)象用equals比較結(jié)果依然是false。面試官最愛追問的是“為什么重寫equals必須重寫hashCode”。這需要從HashMap的查找邏輯講起。HashMap判斷兩個(gè)key是否相同先比較hash值hash相同才用equals確認(rèn)這就是所謂的“先散列后精確”。如果只重寫equals讓兩個(gè)對(duì)象相等卻沒有重寫hashCode那它們的hash值可能不同在同一個(gè)哈希表里會(huì)被分到不同桶位導(dǎo)致你放入的對(duì)象永遠(yuǎn)取不出來。這個(gè)坑我在某公司的會(huì)員系統(tǒng)里真實(shí)遇到過當(dāng)時(shí)用對(duì)象做緩存key重寫了equals沒重寫hashCode結(jié)果緩存命中率驟降排查了大半天才定位到原因。答題的時(shí)候建議順著這個(gè)思路說先解釋和equals的區(qū)別再說明equals重寫的規(guī)則最后用HashMap的get和put過程解釋hashCode的一致性要求。如果還能順帶提一下“hash沖突”的時(shí)候HashMap怎么處理比如鏈表加紅黑樹那這一題就能直接串到集合章節(jié)面試官會(huì)順著你的話繼續(xù)問主動(dòng)權(quán)就到手了。2.3 重載和重寫別被“靜態(tài)分派”這幾個(gè)字嚇住重載是在同一個(gè)類里方法名相同、參數(shù)列表不同它發(fā)生在編譯期Java通過編譯時(shí)的靜態(tài)類型來決定調(diào)用哪個(gè)方法。重寫發(fā)生在繼承體系中子類重新定義父類的方法方法簽名相同運(yùn)行時(shí)會(huì)根據(jù)對(duì)象的實(shí)際類型動(dòng)態(tài)分派。很多初級(jí)選手以為區(qū)別只在于“一個(gè)在類內(nèi)、一個(gè)在父子類”這沒錯(cuò)但不夠深入。加分答法要提到編譯期和運(yùn)行期的差異。重載是按照編譯時(shí)聲明的引用類型來選擇方法的所以有“如果父類變量指向子類對(duì)象調(diào)用重載方法時(shí)走的是父類的靜態(tài)類型”這種反直覺現(xiàn)象。重寫則是運(yùn)行時(shí)看堆里實(shí)際對(duì)象的類型也就是多態(tài)的底層機(jī)制。如果能順帶講一講JVM方法表和方法調(diào)用的指令比如invokevirtual、invokestatic這個(gè)答案的深度就出來了。我在回答這類問題時(shí)會(huì)咨詢一個(gè)簡(jiǎn)單的例子來強(qiáng)化記憶定義一個(gè)父類和一個(gè)子類子類里重載一個(gè)方法同時(shí)重寫另一個(gè)方法。然后分別用父類引用和子類引用去調(diào)用看看哪個(gè)走編譯期哪個(gè)走運(yùn)行期。自己動(dòng)手寫一遍之后面試時(shí)再也不會(huì)混淆。3. 集合框架面試官最愛的源碼拷問區(qū)域3.1 HashMap的put流程、擴(kuò)容時(shí)機(jī)和“為什么是8”HashMap是Java面試的必考題沒有之一。面試官哪怕不問別的地也一定會(huì)碰它。完整的put流程可以概括為先計(jì)算key的hash根據(jù)hash定位到數(shù)組桶位如果桶為空就直接放入如果桶不為空則判斷頭節(jié)點(diǎn)是否相同key相同就覆蓋不同就尾插JDK8及以后進(jìn)入鏈表或樹結(jié)構(gòu)。如果鏈表長(zhǎng)度達(dá)到閾值8且數(shù)組長(zhǎng)度達(dá)到64鏈表會(huì)轉(zhuǎn)成紅黑樹。擴(kuò)容時(shí)機(jī)是另一個(gè)必問點(diǎn)。默認(rèn)初始容量16負(fù)載因子0.75也就是說元素個(gè)數(shù)超過12的時(shí)候就觸發(fā)擴(kuò)容。擴(kuò)容后數(shù)組容量翻倍元素需要重新計(jì)算位置。這里要提一個(gè)細(xì)節(jié)擴(kuò)容不是簡(jiǎn)單復(fù)制而是重新分配桶位因?yàn)槿萘孔兞嗽厮诘耐跋聵?biāo)會(huì)重新計(jì)算這也是擴(kuò)容代價(jià)高的原因。關(guān)于“為什么閾值是8”這個(gè)問題很多參考答案只是搬了源碼注釋里的泊松分布。建議的回答是分兩層第一層是概率上在隨機(jī)哈希的情況下鏈表長(zhǎng)度達(dá)到8的概率極低大約是千萬分之六用這個(gè)閾值可以在時(shí)間和空間上取得平衡第二層是性能上鏈表查詢是O(n)紅黑樹是O(log n)閾值太低樹化頻繁代價(jià)大閾值太高又失去了優(yōu)化意義。最后可以補(bǔ)充一點(diǎn)即使達(dá)到了8如果數(shù)組長(zhǎng)度小于64HashMap會(huì)優(yōu)先選擇擴(kuò)容而不是樹化因?yàn)閿U(kuò)容可以打散鏈表元素更劃算。3.2 ArrayList與LinkedList的復(fù)雜度之爭(zhēng)不要只會(huì)背結(jié)論ArrayList底層是動(dòng)態(tài)數(shù)組LinkedList底層是雙向鏈表。大多數(shù)人都能說出來“數(shù)組查詢快、增刪慢鏈表增刪快、查詢慢”這個(gè)結(jié)論。但面試官在追問之后你會(huì)發(fā)現(xiàn)結(jié)論很多時(shí)候是有條件的。比如LinkedList的增刪操作只有在指定位置、并且已經(jīng)拿到了該位置的節(jié)點(diǎn)引用時(shí)才真正是O(1)。如果你通過add(index, element)在中間插入首先還是得從頭遍歷找到index位置的節(jié)點(diǎn)復(fù)雜度其實(shí)是O(n)。我見過一個(gè)恒生電子的面試官故意讓人掉進(jìn)這個(gè)陷阱問到LinkedList插入復(fù)雜度時(shí)很多候選人脫口而出O(1)完全沒有意識(shí)到查找過程的存在。ArrayList的增刪也同樣有隱藏成本。在尾部追加是O(1)但插入中間需要移動(dòng)后續(xù)元素復(fù)雜度是O(n)刪除元素后數(shù)組需要向前移動(dòng)也是O(n)。所以真實(shí)項(xiàng)目中“增刪快”并不一定用LinkedList反而因?yàn)殒湵砉?jié)點(diǎn)占用空間更大、Cache局部性更差在現(xiàn)代電腦上經(jīng)常不占優(yōu)勢(shì)。回答這一題的高階策略是從底層結(jié)構(gòu)推導(dǎo)復(fù)雜度而不是背結(jié)論最好還能帶一下“實(shí)際項(xiàng)目中優(yōu)先用ArrayList”的使用經(jīng)驗(yàn)。3.3 ConcurrentHashMap的鎖粒度演進(jìn)從分段鎖到CAS加synchronizedConcurrentHashMap也是并發(fā)方向的經(jīng)典題不過很多人只是記結(jié)論說“它線程安全”。面試官一旦追問“為什么線程安全”“和Hashtable有什么區(qū)別”就需要從歷史演進(jìn)講起。JDK7時(shí)代ConcurrentHashMap采用的是分段鎖默認(rèn)16段每段鎖獨(dú)立所以理論上并發(fā)度最高是16。到了JDK8直接顛覆了設(shè)計(jì)不再有Segment而是用CAS加synchronized來保證線程安全。put操作時(shí)如果目標(biāo)桶為空就用CAS直接放入如果桶不為空就用synchronized鎖住頭節(jié)點(diǎn)再進(jìn)行插入或更新。為什么改成這種設(shè)計(jì)可以從兩個(gè)角度解釋。第一是鎖粒度更細(xì)JDK8的鎖只針對(duì)單個(gè)桶而不是一段區(qū)域并發(fā)沖突概率更低。第二是synchronized在JDK6之后經(jīng)歷了鎖升級(jí)優(yōu)化性能已經(jīng)很接近甚至優(yōu)于ReentrantLock沒有必要再單獨(dú)維護(hù)一套分段鎖結(jié)構(gòu)?；卮饡r(shí)可以畫龍點(diǎn)睛地提一句從Hashtable全方法加鎖到JDK7的分段鎖再到JDK8的鎖桶整個(gè)演進(jìn)主線就是鎖粒度越來越細(xì)、并發(fā)能力越來越強(qiáng)。4. 并發(fā)編程最考驗(yàn)深度也最容易暴露水平的板塊4.1 synchronized與ReentrantLock的取舍為什么要選一個(gè)“老的”鎖并發(fā)問題幾乎每個(gè)Java崗位都問區(qū)別只在問多深。最基礎(chǔ)的當(dāng)然是synchronized和ReentrantLock的區(qū)別。這是一個(gè)需要系統(tǒng)性答案的問題我建議按以下幾個(gè)維度組織是否可中斷、是否支持公平鎖、是否支持多個(gè)Condition條件、性能對(duì)比、語法便利性。簡(jiǎn)單來講synchronized是JVM層面的關(guān)鍵字使用簡(jiǎn)單發(fā)生異常時(shí)JVM會(huì)自動(dòng)釋放鎖。JDK6引入偏向鎖、輕量級(jí)鎖、重量級(jí)鎖的升級(jí)過程之后普通場(chǎng)景下性能和ReentrantLock差距已經(jīng)不大了。ReentrantLock是Java類庫(kù)提供的功能它需要手動(dòng)lock和unlock通常配合finally使用。它的優(yōu)勢(shì)在于支持響應(yīng)中斷、支持嘗試獲取鎖tryLock、支持公平鎖以及可以通過多個(gè)Condition實(shí)現(xiàn)更靈活的條件等待。我習(xí)慣把ReentrantLock的三個(gè)獨(dú)占優(yōu)勢(shì)當(dāng)口訣來記可中斷、可超時(shí)、可公平。面試?yán)锶绻犆嬖嚬賳枴笆裁磿r(shí)候用ReentrantLock”可以結(jié)合一個(gè)實(shí)際場(chǎng)景回答比如需要對(duì)鎖等待時(shí)間做限制的場(chǎng)景或者需要公平排隊(duì)避免饑餓的場(chǎng)景。只要?jiǎng)e說出“synchronized已經(jīng)過時(shí)了”這種話就行面試官更希望聽到你理解兩者定位的差異而不是非此即彼。4.2 CAS的三大問題ABA、自旋開銷和只能保證一個(gè)變量CAS是并發(fā)編程里的高頻底牌面試官問“樂觀鎖實(shí)現(xiàn)原理”時(shí)往往就指向它。CAS全稱比較并交換底層通過CPU指令實(shí)現(xiàn)“比較再更新”的原子操作。Java里的AtomicInteger就是靠它實(shí)現(xiàn)的。這一題的加分點(diǎn)在于能講出CAS的三大問題。第一個(gè)是ABA問題值從A變成B再變成ACAS無法感知中間變化解決思路是用版本號(hào)Java里的AtomicStampedReference就是干這個(gè)的。第二個(gè)是自旋帶來的CPU開銷高并發(fā)下CAS反復(fù)失敗大量線程空轉(zhuǎn)消耗CPU解決思路是自適應(yīng)自旋、鎖升級(jí)機(jī)制或者用LongAdder這樣的分段計(jì)數(shù)器。第三個(gè)是只能保證一個(gè)共享變量的原子性多個(gè)變量時(shí)CAS無法直接用需要鎖或者封裝成對(duì)象再通過AtomicReference來操作。如果能結(jié)合自己項(xiàng)目里用AtomicInteger做并發(fā)計(jì)數(shù)的例子來講會(huì)讓人覺得你有真實(shí)調(diào)優(yōu)經(jīng)驗(yàn)。我之前在一個(gè)秒殺系統(tǒng)的庫(kù)存扣減里就用過CAS方案后來發(fā)現(xiàn)單一熱點(diǎn)變量下CAS自旋比synchronized還差就把思路改成了分段計(jì)數(shù)器加定時(shí)合并這個(gè)問題讓我對(duì)CAS的適用邊界有了更清晰的認(rèn)知。4.3 線程池參數(shù)七個(gè)參數(shù)背后的設(shè)計(jì)邏輯Java線程池的七個(gè)參數(shù)幾乎是年年必考面試官甚至?xí)苯幼屇悻F(xiàn)場(chǎng)算“核心線程數(shù)怎么設(shè)置合適”。與其去背公式不如理解每個(gè)參數(shù)存在的意義。七個(gè)參數(shù)分別是核心線程數(shù)、最大線程數(shù)、空閑線程存活時(shí)間、存活時(shí)間單位、工作隊(duì)列、線程工廠、拒絕策略。重點(diǎn)記憶的鏈路是當(dāng)提交任務(wù)時(shí)如果當(dāng)前線程數(shù)小于核心線程數(shù)創(chuàng)建新線程執(zhí)行如果大于核心線程數(shù)任務(wù)進(jìn)入隊(duì)列如果隊(duì)列滿了且線程數(shù)小于最大線程數(shù)創(chuàng)建臨時(shí)線程如果隊(duì)列滿了且線程數(shù)達(dá)到最大線程數(shù)觸發(fā)拒絕策略。這個(gè)流程幾乎每個(gè)架構(gòu)師面試都會(huì)考建議一定要默背并畫出來。關(guān)于核心線程數(shù)的設(shè)置比較靠譜的思路是分場(chǎng)景。CPU密集型任務(wù)核心線程數(shù)建議設(shè)為CPU核數(shù)加一這樣可以降低線程切換開銷IO密集型任務(wù)因?yàn)榇罅繒r(shí)間在等待IO可以設(shè)置到CPU核數(shù)的兩倍甚至更多。不過公式只是參考真實(shí)項(xiàng)目里最好還是先壓測(cè)再調(diào)整。拒絕策略也是高頻追問ThreadPoolExecutor內(nèi)置了AbortException拋異常、Discard靜默丟棄、DiscardOldest丟棄隊(duì)列最老任務(wù)、CallerRuns調(diào)用者自己執(zhí)行四種實(shí)際場(chǎng)景中我通常選CallerRuns因?yàn)樗茏屓蝿?wù)不丟同時(shí)借助調(diào)用線程執(zhí)行形成天然限流。4.4 volatile的可見性和有序性從雙重檢查鎖理解它volatile是并發(fā)高頻題里的穩(wěn)定釘子戶。兩個(gè)核心語義是可見性和有序性?？梢娦灾竩olatile修飾的變量被一個(gè)線程修改后會(huì)立即刷新到主內(nèi)存其他線程讀到的都是最新值。有序性指編譯器或CPU不能把volatile變量相關(guān)的指令重排序到讀寫前后之外。講解這兩個(gè)語義最經(jīng)典的場(chǎng)景是單例模式的雙重檢查鎖。第一層判空是為了避免不必要的加鎖第二層判空是為了防止多個(gè)線程同時(shí)創(chuàng)建實(shí)例。但如果不加volatile修飾即使在synchronized塊內(nèi)部創(chuàng)建對(duì)象也可能出問題。原因是“new Singleton()”這一步在JVM層面不是原子操作它包含了分配內(nèi)存、初始化對(duì)象、把引用指向內(nèi)存三個(gè)步驟其中第2步和第3步可能被重排。如果線程A先完成了第3步但沒完成第2步線程B進(jìn)來判空發(fā)現(xiàn)引用不為空直接拿去用就會(huì)拿到一個(gè)尚未初始化完成的對(duì)象。這一類解釋問到細(xì)節(jié)時(shí)最容易得分。你會(huì)看到面試官點(diǎn)頭因?yàn)榇蠖鄶?shù)候選人只背“volatile保證可見性和有序性”這句話說不出具體場(chǎng)景。順帶再提一句volatile不保證原子性比如i這種復(fù)合操作還是需要Atomic類或鎖這一題的完整度就很高了。5. JVM內(nèi)存布局、垃圾回收和一次線上Full GC調(diào)優(yōu)5.1 運(yùn)行時(shí)數(shù)據(jù)區(qū)六個(gè)區(qū)域里最容易混淆的兩個(gè)JVM運(yùn)行時(shí)數(shù)據(jù)區(qū)幾乎是必考基礎(chǔ)。堆、虛擬機(jī)棧、本地方法棧、方法區(qū)、程序計(jì)數(shù)器、常量池每個(gè)區(qū)域干什么、哪里會(huì)溢出這些問題不難但需要系統(tǒng)性組織。我推薦按“線程共享與線程私有”作為分類主線來講。堆和方法區(qū)是所有線程共享的虛擬機(jī)棧、本地方法棧、程序計(jì)數(shù)器是線程私有的。最容易混淆的是方法區(qū)和堆的關(guān)系以及常量池到底放在哪里。JDK8之前字符串常量池在方法區(qū)里的永久代JDK8之后永久代被元空間取代字符串常量池被移到了堆中。這直接影響你之前了解到的String.intern的返回值判斷也會(huì)引出一個(gè)經(jīng)典問法“new一個(gè)字符串和直接賦值字符串的區(qū)別”。另一個(gè)容易混淆的點(diǎn)是虛擬機(jī)棧和本地方法棧前者服務(wù)Java方法后者服務(wù)native方法HotSpot虛擬機(jī)把它們合并成一個(gè)了。我的記憶方法是像回憶自己居住的小區(qū)一樣堆是公共活動(dòng)廣場(chǎng)所有人都能去棧是每戶的私人房間線程各進(jìn)各的屋方法區(qū)是小區(qū)公告欄存類型信息和常量。這樣解釋雖然不夠精確但面試中用來先回答“大概”再補(bǔ)充細(xì)節(jié)就能給面試官留下“理解到位”的印象。5.2 垃圾回收對(duì)象怎么判斷死亡又有哪些常用采集器判斷對(duì)象是否存活的標(biāo)準(zhǔn)是可達(dá)性分析而不是簡(jiǎn)單的引用計(jì)數(shù)。從GC Roots出發(fā)沿著引用鏈往下找能到達(dá)的對(duì)象就是存活的否則可以被回收。常見的GC Roots包括虛擬機(jī)棧中引用的對(duì)象、方法區(qū)中靜態(tài)屬性引用的對(duì)象、常量引用的對(duì)象、JNI引用的對(duì)象等等。這塊答起來相對(duì)固定背清楚主流觀點(diǎn)就可以了但要注意別把應(yīng)用計(jì)數(shù)說成主流因?yàn)檠h(huán)引用問題就可以直接反駁掉引用計(jì)數(shù)法。垃圾收集器方面重點(diǎn)關(guān)注G1。G1的特點(diǎn)是分區(qū)收集、可預(yù)測(cè)停頓它將堆劃分為多個(gè)大小相等的Region通過維護(hù)每個(gè)Region的回收價(jià)值和回收成本來決定優(yōu)先回收哪些Region。這才是G1名字的“Garbage First”的由來?；卮饡r(shí)可以對(duì)比CMSCMS的兩個(gè)著名缺點(diǎn)是內(nèi)存碎片化以及并發(fā)階段資源消耗高G1通過整理算法避免了碎片同時(shí)可以設(shè)置預(yù)期的停頓時(shí)間。如果面試官問到ZGC可以簡(jiǎn)要提一下它通過染色指針和讀屏障實(shí)現(xiàn)了幾乎不影響吞吐的極短停頓不過需要小心別被追問得太深。我的經(jīng)驗(yàn)是聊垃圾回收器時(shí)不要變成背誦各個(gè)收集器的參數(shù)表而要把重心放在“如何根據(jù)業(yè)務(wù)選擇合適收集器”的思路上面試官更想聽到你具備選型能力。5.3 一次線上Full GC調(diào)優(yōu)的真實(shí)排障過程我在某次線上壓測(cè)時(shí)遇到過Full GC頻繁觸發(fā)的問題這個(gè)案例我經(jīng)常在復(fù)盤時(shí)用到?，F(xiàn)象是系統(tǒng)運(yùn)行十分鐘左右接口RT突然飆升日志里大量出現(xiàn)GC日志Young GC后老年代占用快速上升最終觸發(fā)Full GC。當(dāng)時(shí)我沒有直接去調(diào)整堆大小而是先抓堆dump和GC日志發(fā)現(xiàn)在老年代里大量存活對(duì)象是同一個(gè)業(yè)務(wù)緩存對(duì)象而且這個(gè)緩存對(duì)象沒有設(shè)置過期時(shí)間還不斷被新請(qǐng)求寫入導(dǎo)致老年代逐漸被占滿。這類問題的定位思路比具體參數(shù)更重要。第一步是看GC日志明確是Young GC頻繁還是Full GC頻繁第二步是抓堆dump找到占用內(nèi)存最大的對(duì)象類型第三步是回到代碼里查看這些對(duì)象是誰創(chuàng)建的、為什么沒被回收。最終我們把這個(gè)緩存的寫入頻率降下來給緩存加上了過期時(shí)間又調(diào)整了新生代和老年代的比例Full GC頻率從每分鐘幾次降到幾小時(shí)一次。在面試中講這種親身經(jīng)歷是不管多有效的八股文都比不上。哪怕你的經(jīng)歷很普通只要是真實(shí)踩坑后總結(jié)出來的面試官都能感覺到。6. Spring核心IoC容器、AOP和事務(wù)那些不遇坑不知深的點(diǎn)6.1 Bean的生命周期與循環(huán)依賴三級(jí)緩存里到底緩存了什么Spring是Java后端面試的半壁江山而Bean生命周期又是Spring的半壁江山。完整生命周期包括實(shí)例化、屬性填充、初始化、使用、銷毀幾個(gè)階段其中穿插著BeanPostProcessor的各個(gè)擴(kuò)展點(diǎn)。能說清楚這些基本可以證明你對(duì)Spring容器有真理解。循環(huán)依賴是常考的深水區(qū)。Spring解決單例setter注入循環(huán)依賴靠的是三級(jí)緩存。第一級(jí)緩存里放的是已經(jīng)完成初始化的成品Bean第二級(jí)緩存里放的是提前暴露的早期Bean已經(jīng)實(shí)例化且完成屬性填充但還沒執(zhí)行初始化方法第三級(jí)緩存里放的是ObjectFactory也就是一個(gè)能生成代理對(duì)象的工廠。三級(jí)緩存的必要性在于如果Bean需要AOP代理第三級(jí)的ObjectFactory可以在提前暴露時(shí)生成代理對(duì)象從而保證最終注入的和實(shí)際使用的是同一個(gè)代理?；卮鹧h(huán)依賴的關(guān)鍵是區(qū)分構(gòu)造器注入和setter注入。構(gòu)造器注入天然無法解決循環(huán)依賴因?yàn)锽ean在創(chuàng)建時(shí)需要先有依賴對(duì)象這在一個(gè)相互依賴的構(gòu)造過程中會(huì)直接報(bào)錯(cuò)。而setter注入可以在實(shí)例化之后再填充屬性所以才能利用三級(jí)緩存提前暴露半成品。理解了這一點(diǎn)你就能解釋為什么Spring官方推薦構(gòu)造器注入不是因?yàn)檠h(huán)依賴而是因?yàn)樗ＷC了依賴的不可變更性。6.2 AOP代理失效為什么自調(diào)用走不到攔截邏輯AOP的面試題通常集中在“哪些情況下AOP會(huì)失效”。最常見的場(chǎng)景是同一個(gè)類里的方法自調(diào)用。比如一個(gè)類里方法A調(diào)用方法BB上標(biāo)了TransactionalA沒有標(biāo)此時(shí)B的事務(wù)是不會(huì)生效的。原因是AOP基于代理外部調(diào)用進(jìn)入的是代理對(duì)象事務(wù)通過代理對(duì)象的方法攔截來實(shí)現(xiàn)但A方法在執(zhí)行時(shí)調(diào)用B方法用的是this調(diào)用this指向的是原始對(duì)象而不是代理對(duì)象自然繞過攔截器。類似的原因也能解釋為什么private方法上標(biāo)注的Transactional不生效因?yàn)榇韺?duì)象無法增強(qiáng)private方法。還有一種是類沒有被Spring管理比如new出來的對(duì)象調(diào)方法那更不可能有AOP生效。最后的總結(jié)建議把“AOP生效的前提是方法經(jīng)由代理對(duì)象調(diào)用”這句話當(dāng)提綱面試官喜歡聽到你對(duì)本質(zhì)的概括而不是一個(gè)個(gè)孤立場(chǎng)景的羅列。6.3 Transactional事務(wù)失效的五個(gè)典型場(chǎng)景事務(wù)失效的坑幾乎是必考清單而且出題人很喜歡把場(chǎng)景做成選擇題“以下哪個(gè)方法事務(wù)會(huì)失效為什么”。我總結(jié)過一份高頻失效原因清單按出現(xiàn)頻率排列方法內(nèi)部自調(diào)用導(dǎo)致代理失效異常被try-catch吞掉事務(wù)感知不到拋出的是檢查異常而事務(wù)默認(rèn)只對(duì)RuntimeException回滾方法被非public修飾數(shù)據(jù)庫(kù)引擎不支持事務(wù)比如MyISAM其中“異常被吞”和“檢查異常不回滾”是最容易混淆的。默認(rèn)情況下Spring只對(duì)RuntimeException和Error回滾如果你故意捕獲了異常事務(wù)就無法知道發(fā)生了什么自然不會(huì)回滾。想說服面試官你理解了事務(wù)的底層機(jī)制可以說Spring事務(wù)本質(zhì)是AOP切面它捕捉到方法拋出異常才執(zhí)行回滾邏輯如果異常根本沒有傳播出來切面就認(rèn)為方法執(zhí)行成功。這么一解釋前面的五個(gè)場(chǎng)景全都串起來了。7. 數(shù)據(jù)庫(kù)索引、事務(wù)隔離和一條慢SQL的排查鏈路7.1 為什么索引底層用B樹而非其他樹數(shù)據(jù)庫(kù)索引是Java后端面試和實(shí)際開發(fā)的交匯點(diǎn)。最常問的是“為什么MySQL InnoDB索引用B樹而不用二叉樹、哈希表、B樹”。這個(gè)問題有一個(gè)很好的回答框架從每種數(shù)據(jù)結(jié)構(gòu)的特性出發(fā)分析它為什么不適合。哈希表等值查詢最快但做不了范圍查詢所以直接排除。二叉搜索樹極端情況下會(huì)退化成了鏈表同時(shí)也無法支撐千萬級(jí)數(shù)據(jù)的存儲(chǔ)樹太深會(huì)導(dǎo)致磁盤IO過多。紅黑樹雖然平衡但同樣存在樹深問題不適合磁盤這種每次訪問都有固定代價(jià)的介質(zhì)。B樹每個(gè)節(jié)點(diǎn)可以存儲(chǔ)多個(gè)關(guān)鍵字降低了樹高但它的數(shù)據(jù)分散在每個(gè)節(jié)點(diǎn)上做范圍查詢時(shí)中序遍歷復(fù)雜。B樹把所有數(shù)據(jù)存在葉子節(jié)點(diǎn)葉子節(jié)點(diǎn)之間通過指針串聯(lián)成鏈表這樣范圍查詢只需要遍歷鏈表加上非葉子節(jié)點(diǎn)只存索引不存數(shù)據(jù)一個(gè)節(jié)點(diǎn)能放更多索引樹高進(jìn)一步降低磁盤IO次數(shù)更少?；卮鸬臅r(shí)候能把這個(gè)推導(dǎo)過程講明白比直接背“B樹更合適”要有說服力得多。如果還可以補(bǔ)充聚簇索引和非聚簇索引的區(qū)別以及回表概念這題基本就滿分了。7.2 事務(wù)隔離級(jí)別與MVCC的關(guān)聯(lián)事務(wù)隔離級(jí)別包括讀未提交、讀已提交、可重復(fù)讀、串行化。從名詞解釋到存在的問題這一塊是數(shù)據(jù)庫(kù)面試的常規(guī)必考。讀未提交會(huì)有臟讀讀已提交解決了臟讀但會(huì)有不可重復(fù)讀可重復(fù)讀解決了不可重復(fù)讀但可能還有幻讀串行化可以杜絕所有問題但性能極差。MySQL InnoDB默認(rèn)隔離級(jí)別是可重復(fù)讀但它實(shí)際上也基本解決了幻讀。解決方案有兩種一是MVCC多版本并發(fā)控制利用隱藏字段和undo日志生成快照在普通讀場(chǎng)景下事務(wù)讀取的是快照版本不會(huì)被其他事務(wù)新插入的數(shù)據(jù)影響二是當(dāng)前讀場(chǎng)景下比如select for update會(huì)通過間隙鎖把范圍內(nèi)的所有間隙鎖住防止其他事務(wù)在范圍內(nèi)插入數(shù)據(jù)。把這兩個(gè)機(jī)制講清楚面試官就會(huì)覺得你真的理解隔離級(jí)別而不是停留在數(shù)據(jù)庫(kù)教科書層面。7.3 一條慢SQL是這么被排查出來的面試題經(jīng)常給一個(gè)場(chǎng)景某個(gè)接口突然很慢數(shù)據(jù)庫(kù)CPU升高你怎么排查。這題考察的是排障思路。我的固定套路是先查慢查詢?nèi)罩菊业骄唧wSQL然后執(zhí)行explain重點(diǎn)看幾個(gè)字段type是否達(dá)到range或ref而不是ALL全表掃描、key是否實(shí)際用到索引、rows掃描行數(shù)是否巨大、Extra里有沒有Using temporary和Using filesort。常見索引失效情況需要背熟比如對(duì)索引列使用函數(shù)或計(jì)算、隱式類型轉(zhuǎn)換、最左前綴原則被破壞、like以%開頭、or條件中有一個(gè)字段無索引。這里有一個(gè)我重復(fù)踩過很多次的坑明明where條件里有索引但字段類型不一致比如字符串字段傳了數(shù)字參數(shù)MySQL可能做隱式轉(zhuǎn)換導(dǎo)致索引失效。排查時(shí)不要光看SQL結(jié)果對(duì)不對(duì)還要注意類型匹配?；叵胍淮蝺?yōu)化某報(bào)表查詢的經(jīng)驗(yàn)一個(gè)耗時(shí)3秒的查詢分析后發(fā)現(xiàn)是兩張大表join連接字段上的字符集不一致導(dǎo)致索引失效修復(fù)之后秒回。這類經(jīng)驗(yàn)在面試?yán)镎f出來比背十條索引優(yōu)化口訣都更能體現(xiàn)實(shí)操能力。8. 分布式場(chǎng)景緩存、鎖和消息隊(duì)列的必問題8.1 緩存穿透、擊穿、雪崩三個(gè)“災(zāi)難”如何應(yīng)對(duì)分布式面試?yán)锞彺娴娜值軒缀醣靥岽┩?、擊穿、雪崩。穿透指的是查詢一個(gè)根本不存在的數(shù)據(jù)緩存和數(shù)據(jù)庫(kù)都沒有每次請(qǐng)求直接打到數(shù)據(jù)庫(kù)。解決思路有布隆過濾器前置攔截以及緩存空值并設(shè)置短過期時(shí)間。建議優(yōu)先用布隆過濾器因?yàn)樗恍枰鎯?chǔ)空值數(shù)據(jù)內(nèi)存占用小缺點(diǎn)是可能有誤判所以還需在數(shù)據(jù)庫(kù)層做好兜底。擊穿指的是熱點(diǎn)key過期的一瞬間大量并發(fā)請(qǐng)求同時(shí)打到數(shù)據(jù)庫(kù)。常見解決方案是互斥鎖和邏輯過期。互斥鎖方案下只有一個(gè)線程去數(shù)據(jù)庫(kù)加載數(shù)據(jù)并寫緩存其余線程等待邏輯過期方案則不設(shè)置物理過期時(shí)間而是存一個(gè)邏輯過期時(shí)間后臺(tái)異步刷新。兩者各有取舍互斥鎖簡(jiǎn)單但會(huì)短暫阻塞邏輯過期不阻塞但實(shí)現(xiàn)復(fù)雜。雪崩指大量key同時(shí)失效或者Redis節(jié)點(diǎn)故障導(dǎo)致數(shù)據(jù)庫(kù)負(fù)載暴增。解決思路主要分兩塊一是讓key過期時(shí)間帶隨機(jī)值避免同一時(shí)間集體失效二是對(duì)Redis做高可用部署加哨兵或集群。如果面試官追問“Redis掛了怎么辦”可以從本地緩存兜底、請(qǐng)求限流和熔斷器三個(gè)層面回答。8.2 分布式鎖Redis與ZooKeeper方案怎么權(quán)衡分布式鎖考察的是你對(duì)CAP和一致性的理解。最基礎(chǔ)方案是Redis的setnx加過期時(shí)間但要注意幾個(gè)坑一是必須保證setnx和expire是原子操作否則鎖沒設(shè)置過期時(shí)間就宕機(jī)其他線程永遠(yuǎn)拿不到鎖二是釋放鎖時(shí)要驗(yàn)證是不是自己加的鎖不能把別人剛持有的鎖誤刪了。Redisson這個(gè)框架通過看門狗機(jī)制自動(dòng)續(xù)期就是為了避免業(yè)務(wù)還沒執(zhí)行完鎖就過期的問題。另一種方案是ZooKeeper的臨時(shí)順序節(jié)點(diǎn)通過創(chuàng)建節(jié)點(diǎn)和監(jiān)聽機(jī)制實(shí)現(xiàn)鎖。臨時(shí)節(jié)點(diǎn)的好處是客戶端會(huì)話斷開節(jié)點(diǎn)會(huì)自動(dòng)刪除不會(huì)出現(xiàn)鎖永久不釋放的問題這比Redis的過期時(shí)間更優(yōu)雅。但ZooKeeper方案吞吐量不如Redis并且每次加鎖都有創(chuàng)建節(jié)點(diǎn)和監(jiān)聽的網(wǎng)絡(luò)開銷性能會(huì)低于Redis方案。面試官問到選型對(duì)比時(shí)我給出的建議是高吞吐場(chǎng)景用Redis強(qiáng)一致和可靠性要求極高的場(chǎng)景用ZooKeeper。如果還有延展空間可以提一下Redlock算法但順手點(diǎn)一句“業(yè)界對(duì)Redlock的爭(zhēng)議也不小”就好不用展開太多。8.3 消息隊(duì)列的可靠性投遞從生產(chǎn)到消費(fèi)的完整鏈路以RabbitMQ或Kafka為例消息可靠性問題可以拆成三段來答。生產(chǎn)端要確保消息不丟常見方案是發(fā)送方確認(rèn)模式比如RabbitMQ的ConfirmCallback或者Kafka的acksall加重試機(jī)制。Broker端要確保消息不丟一方面靠持久化另一方面靠副本機(jī)制Kafka的多副本和ISR機(jī)制就是為這個(gè)設(shè)計(jì)的。消費(fèi)端要保證不丟關(guān)鍵是消費(fèi)完成后才提交offset同時(shí)關(guān)閉自動(dòng)提交避免消息還沒處理完就提交了位點(diǎn)。但最容易被忽略的是“不丟”的另一半是“不重復(fù)”。即使我們做到了不丟重試和網(wǎng)絡(luò)抖動(dòng)還是會(huì)帶來重復(fù)消息所以消費(fèi)端必須冪等。設(shè)計(jì)冪等的手段包括在消費(fèi)邏輯里利用數(shù)據(jù)庫(kù)唯一鍵、Redis分布式鎖或者維護(hù)一個(gè)消費(fèi)去重表。完整的可靠性方案從來不是靠單點(diǎn)而是靠協(xié)議保證加業(yè)務(wù)冪等共同兜底。我見過太多只聊“手動(dòng)ack”就敢說自己懂消息隊(duì)列的候選人一問“重復(fù)消息怎么辦”就卡殼。所以這道題一定要觀點(diǎn)完整最好表達(dá)“生產(chǎn)端不丟、消費(fèi)端不重、冪等兜底”三個(gè)層次這會(huì)讓面試官對(duì)你的系統(tǒng)設(shè)計(jì)能力刮目相看。9. 怎樣把這份清單用出最大價(jià)值先別急著從第一題背到最后一題那樣不僅容易忘還容易把思路背死。我推薦的做法是按模塊來每個(gè)禮拜深攻一個(gè)主題比如這一周專門整理集合框架那么就把HashMap、ConcurrentHashMap、ArrayList、LinkedList放到一起復(fù)習(xí)順便看一遍源碼。面試其實(shí)不怎么考“你背了多少題”它考的是“你會(huì)不會(huì)像程序員一樣思考”而思考能力只能通過反復(fù)推演和寫demo來提升。每道題看完之后拿出一張白紙假裝面前坐著面試官把自己準(zhǔn)備講的思路說一遍。這一步被稱為“費(fèi)曼式學(xué)習(xí)”它的目的是逼著你組織語言當(dāng)你發(fā)現(xiàn)說出口的句子斷斷續(xù)續(xù)說明這個(gè)知識(shí)點(diǎn)還沒真正變成你的。我在準(zhǔn)備面試最緊張的時(shí)候每天都對(duì)著電腦屏幕開錄音然后回放自己的回答這個(gè)過程聽著有點(diǎn)傻但效果極其明顯。最后分享一個(gè)我踩過的坑不要沉溺于“看了很多面經(jīng)”的假象。面經(jīng)的作用是幫你識(shí)別考點(diǎn)而不是代替思考。真正讓面試官記住你的是在某個(gè)問題下面的深度追問里你能比他更快地講出底層細(xì)節(jié)和你的實(shí)戰(zhàn)取舍。這份Java面試題清單會(huì)一直更新下去下一次準(zhǔn)備跳槽的人希望你能從這些題目里看到的不只是“答案”而是背后的知識(shí)網(wǎng)絡(luò)。