路徑)
簡介這份Java高頻面試題PDF面向準備Java后端崗位面試的求職者與初中級開發(fā)者聚焦Spring生態(tài)與數(shù)據(jù)庫調(diào)優(yōu)兩大高頻考點。內(nèi)容系統(tǒng)梳理了Spring Bean生命周期實例化、依賴注入、初始化、銷毀、Spring MVC完整執(zhí)行流程、Spring Boot自動裝配原理以及SQL執(zhí)行計劃解讀、索引失效場景與優(yōu)化技巧、MySQL常見索引類型和B樹底層結(jié)構(gòu)并延伸至線程池種類與核心參數(shù)、拒絕策略等并發(fā)知識點。資源包共1個PDF文件約396KB輕量便攜適合碎片化復習與面試前速查。目前已有180人學習瀏覽。讀者可借此快速串聯(lián)Spring框架核心機制與SQL優(yōu)化思路對照執(zhí)行計劃字段與索引失效清單查漏補缺形成結(jié)構(gòu)化的面試答題框架提升技術表達與實戰(zhàn)應對能力。1. 從一份 Java 高頻面試題 PDF 說起為什么背完答案還是掛面試間里最尷尬的場景不是被問到完全沒聽過的名詞而是題目你見過、答案你背過面試官追問一句“為什么”就卡殼。很多人手里都有一份流傳的 Java 高頻面試題 PDF幾百道題、分類清晰、答案現(xiàn)成看起來是捷徑實際用起來卻像黑匣子——輸入題目、輸出答案中間的理解過程被跳過了。這份 PDF 真正該被當成什么不是背誦手冊而是一張知識地圖的索引。它告訴你哪些點會被反復考但每個點背后的原理、邊界、版本差異得自己補上。這篇文章面向正在準備 Java 后端面試的開發(fā)者尤其是工作一到三年、想從“會寫業(yè)務代碼”跨到“能講清底層機制”的人。我會把這份高頻題 PDF 拆成可復現(xiàn)的學習路徑哪些題必須手寫代碼驗證、哪些參數(shù)要親手調(diào)一遍、哪些坑是面試官最愛追問的。目標很直接——讓你下次被追問時能順著原理往下講三層而不是背完第一層就沒了。2. 把高頻題 PDF 拆成可執(zhí)行的知識模塊先分類再動手拿到一份 Java 高頻面試題 PDF第一反應不該是從第一頁開始背。我一般會先做一次結(jié)構(gòu)拆解把題目按“考察層次”重新歸類因為不同層次的題準備方式完全不同。PDF 的原始分類通常是按知識點排的——集合、并發(fā)、JVM、Spring、數(shù)據(jù)庫——但面試官提問時是混合著來的所以你得自己建一套索引。2.1 按考察層次給題目打標簽記憶層、原理層、設計層記憶層的題答案是事實性的比如“HashMap 默認容量是多少”“ArrayList 和 LinkedList 的區(qū)別”。這類題占比不小但單獨背它們性價比最低因為面試官很少只問事實一定會往原理層追。原理層的題問的是“為什么這樣設計”比如“HashMap 為什么用紅黑樹而不是 AVL”“ConcurrentHashMap 為什么在 JDK 8 改成 CAS synchronized”。設計層的題最開放比如“讓你設計一個本地緩存你會考慮哪些點”它考的是你把前面兩層串起來的能力。我的做法是給 PDF 里每道題標一個層級然后統(tǒng)計比例。如果原理層和設計層的題加起來不到一半說明這份 PDF 偏基礎你得自己補深度如果超過七成那它更適合當復習提綱而不是入門材料。這個判斷決定了你后面花多少時間在動手驗證上。2.2 用最小代碼驗證記憶層結(jié)論以 HashMap 擴容為例記憶層的結(jié)論最容易記錯也最容易被追問翻車。與其死記不如寫一段最小代碼跑一遍。下面這段代碼用來觀察 HashMap 的擴容時機和容量變化注意我加了反射讀取內(nèi)部閾值這是理解擴容邏輯的關鍵。import java.lang.reflect.Field; import java.util.HashMap; import java.util.Map; public class HashMapProbe { public static void main(String[] args) throws Exception { MapString, Integer map new HashMap(); // 反射拿到 table 和 threshold 字段觀察擴容 Field tableField HashMap.class.getDeclaredField(table); tableField.setAccessible(true); Field thresholdField HashMap.class.getDeclaredField(threshold); thresholdField.setAccessible(true); for (int i 0; i 20; i) { map.put(key i, i); Object[] table (Object[]) tableField.get(map); int threshold (int) thresholdField.get(map); int capacity table null ? 0 : table.length; System.out.printf(size%d, capacity%d, threshold%d%n, map.size(), capacity, threshold); } } }這段代碼的邏輯說明HashMap 在第一次 put 時才初始化 table默認容量 16、負載因子 0.75所以閾值是 12。當 size 超過閾值時觸發(fā)擴容容量翻倍閾值也翻倍。運行后你會看到 capacity 從 0 跳到 16再到 32threshold 從 0 到 12 再到 24。參數(shù)說明負載因子 0.75 是空間和時間的折中調(diào)大減少擴容但增加哈希沖突調(diào)小相反初始容量如果提前知道數(shù)據(jù)量應該設為預期元素數(shù) / 0.75 1避免多次擴容。這個結(jié)論背下來只要一句話但親手跑一遍面試官問“為什么是 0.75”時你就能從泊松分布和沖突概率的角度答而不是說“書上寫的”。2.3 給并發(fā)題建一張參數(shù)對照表synchronized 與 ReentrantLock并發(fā)是高頻題里最容易答得含糊的部分。我習慣把關鍵類做成對照表面試前掃一遍比背大段文字有效。下面這張表覆蓋了最常被對比的兩個鎖參數(shù)和邊界都列清楚。對比項synchronizedReentrantLock鎖獲取方式JVM 內(nèi)置自動釋放顯式 lock/unlock需 finally 釋放可中斷不支持lockInterruptibly 支持超時獲取不支持tryLock(timeout) 支持公平鎖非公平可選公平/非公平條件變量wait/notify 單一可創(chuàng)建多個 Condition鎖升級偏向鎖→輕量級→重量級無升級概念基于 AQS這張表不是讓你背而是讓你在回答時能快速定位差異點。比如面試官問“什么時候用 ReentrantLock”你就能從可中斷、超時、多條件三個場景切入而不是籠統(tǒng)說“更靈活”。參數(shù)上要特別注意ReentrantLock 的公平鎖會降低吞吐非公平鎖可能造成線程饑餓默認非公平是有性能考慮的。這些邊界在 PDF 的答案里往往只有一句話但面試官追問時就是分水嶺。3. 用 JVM 和并發(fā)兩條線串起 PDF 里的硬骨頭高頻題 PDF 里真正拉開差距的是 JVM 和并發(fā)這兩塊。它們題目多、追問深、光靠背結(jié)論必翻車。我的策略是各選一條主線把零散的題掛上去形成能自己推演的鏈條。3.1 JVM 內(nèi)存結(jié)構(gòu)從一道“對象在哪分配”追到逃逸分析PDF 里常有一道題“對象一定分配在堆上嗎”標準答案是不一定可能棧上分配。但面試官接著會問“什么情況下棧上分配”這就到了逃逸分析。要講清楚這條鏈得先理清 JVM 內(nèi)存結(jié)構(gòu)程序計數(shù)器、虛擬機棧、本地方法棧、堆、方法區(qū)JDK 8 后是元空間。對象分配的主戰(zhàn)場是堆但 JIT 編譯器在逃逸分析后可能做標量替換把對象拆成基本類型放在棧上。驗證這件事需要動手調(diào)參數(shù)。下面這組 JVM 參數(shù)用來觀察逃逸分析的效果注意-XX:PrintEscapeAnalysis在部分版本需要 debug 版 JVM生產(chǎn)環(huán)境一般用-XX:DoEscapeAnalysis開啟即可。# 開啟逃逸分析關閉標量替換做對比 java -XX:DoEscapeAnalysis -XX:-EliminateAllocations -Xmx256m -jar demo.jar # 開啟逃逸分析并允許標量替換 java -XX:DoEscapeAnalysis -XX:EliminateAllocations -Xmx256m -jar demo.jar邏輯說明DoEscapeAnalysis控制是否做逃逸分析EliminateAllocations控制是否允許標量替換。兩個都開時未逃逸的對象可能被拆散分配在棧上減少堆壓力。參數(shù)說明-Xmx256m限制堆大小方便觀察 GC 頻率變化如果對象確實逃逸了比如被返回或存入全局集合逃逸分析不會生效這時調(diào)參也沒用。常見誤用是以為開了逃逸分析所有對象就上棧實際上它只對未逃逸的局部對象生效而且受 JIT 編譯閾值影響方法得被調(diào)用足夠多次才會觸發(fā)優(yōu)化。面試時能講清“逃逸分析是 JIT 的優(yōu)化手段不是 JVM 規(guī)范強制”就已經(jīng)超過大多數(shù)候選人了。3.2 并發(fā)工具類用 CountDownLatch 和 CyclicBarrier 做對照實驗并發(fā)題里 CountDownLatch 和 CyclicBarrier 經(jīng)常被放在一起問很多人背了“一個減一個加”就完事但面試官會追問使用場景和異常處理。我一般寫兩個最小 Demo 跑一遍把行為差異刻進記憶。import java.util.concurrent.CountDownLatch; import java.util.concurrent.CyclicBarrier; import java.util.concurrent.TimeUnit; public class LatchVsBarrier { public static void main(String[] args) throws Exception { // CountDownLatch主線程等 3 個子任務完成 CountDownLatch latch new CountDownLatch(3); for (int i 0; i 3; i) { new Thread(() - { try { TimeUnit.MILLISECONDS.sleep(100); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } System.out.println(Thread.currentThread().getName() done); latch.countDown(); }).start(); } latch.await(); System.out.println(all tasks finished); // CyclicBarrier3 個線程互相等待到齊后繼續(xù) CyclicBarrier barrier new CyclicBarrier(3, () - System.out.println(barrier action executed)); for (int i 0; i 3; i) { new Thread(() - { try { System.out.println(Thread.currentThread().getName() waiting); barrier.await(); System.out.println(Thread.currentThread().getName() passed); } catch (Exception e) { Thread.currentThread().interrupt(); } }).start(); } } }邏輯說明CountDownLatch 是一次性的計數(shù)減到零后所有 await 的線程被釋放主線程繼續(xù)CyclicBarrier 是可循環(huán)的每個線程 await 后等其他人到齊然后一起繼續(xù)還能指定到齊后執(zhí)行的動作。參數(shù)說明CountDownLatch 的構(gòu)造參數(shù)是計數(shù)初始值必須和任務數(shù)一致調(diào)大了會永久阻塞CyclicBarrier 的構(gòu)造參數(shù)是參與線程數(shù)如果某個線程在 await 前拋異常其他線程會收到 BrokenBarrierException這是排查時最常忽略的點。常見誤用是把 CyclicBarrier 當 CountDownLatch 用結(jié)果發(fā)現(xiàn)它不能“一個線程等多個”因為它是互相等。面試時能說出“CyclicBarrier 的 await 會拋 BrokenBarrierException需要處理”就是加分項。3.3 線程池參數(shù)把 PDF 里的七個參數(shù)落到一次壓測里線程池的七個參數(shù)幾乎每份 PDF 都有但背下來和會調(diào)是兩回事。核心線程數(shù)、最大線程數(shù)、空閑時間、時間單位、阻塞隊列、線程工廠、拒絕策略這七個里最容易翻車的是隊列和拒絕策略的組合。我一般用一段代碼模擬任務提交觀察不同隊列下的行為。import java.util.concurrent.*; public class PoolProbe { public static void main(String[] args) { // 核心 2最大 4隊列容量 2觀察拒絕時機 ThreadPoolExecutor pool new ThreadPoolExecutor( 2, 4, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(2), Executors.defaultThreadFactory(), new ThreadPoolExecutor.AbortPolicy()); for (int i 0; i 10; i) { final int id i; try { pool.execute(() - { System.out.println(task id running on Thread.currentThread().getName()); try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); } catch (RejectedExecutionException e) { System.out.println(task id rejected); } } pool.shutdown(); } }邏輯說明任務提交時先看核心線程是否滿沒滿就新建核心線程核心滿了進隊列隊列滿了看最大線程是否滿沒滿就新建非核心線程都滿了觸發(fā)拒絕策略。參數(shù)說明ArrayBlockingQueue(2)容量為 2所以前 2 個任務占核心線程第 3、4 個進隊列第 5、6 個占最大線程第 7 個開始被拒絕。如果把隊列換成LinkedBlockingQueue無界隊列最大線程數(shù)就永遠不會被觸發(fā)任務會一直堆積直到 OOM這是生產(chǎn)環(huán)境最常見的坑。拒絕策略里 AbortPolicy 拋異常CallerRunsPolicy 讓提交線程自己跑DiscardPolicy 靜默丟棄DiscardOldestPolicy 丟最老的。面試時能說清“無界隊列會讓 maximumPoolSize 失效”比背七個參數(shù)名字有用得多。4. 避坑與排查高頻題準備里最容易翻車的五件事準備 Java 面試的過程中有些坑幾乎每個人都會踩而且踩了之后還以為是題目太難。下面這五條是我自己和身邊人反復驗證過的按“現(xiàn)象→原因→解決”寫清楚。4.1 現(xiàn)象答案背得滾瓜爛熟一追問就斷片原因記憶層和原理層混在一起背沒有建立因果鏈。PDF 的答案往往是結(jié)論式的比如“HashMap 線程不安全”但沒告訴你為什么不安全、什么場景下會出問題。解決每背一個結(jié)論強制自己問三個“為什么”然后寫最小代碼驗證。比如“線程不安全”就去跑多線程 put觀察死循環(huán)或數(shù)據(jù)丟失親手復現(xiàn)一次比背十遍都牢。4.2 現(xiàn)象JVM 參數(shù)題答得頭頭是道實際調(diào)優(yōu)時不敢下手原因參數(shù)是背的沒在真實或模擬環(huán)境里調(diào)過。比如-Xmn設多大、-XX:SurvivorRatio怎么算光看公式記不住。解決本地起一個 Spring Boot 小服務用-Xmx256m -Xmn128m跑一遍再用jstat -gc觀察 Eden、Survivor、Old 區(qū)的變化把參數(shù)和 GC 日志對應起來。參數(shù)說明jstat -gc pid 1000每秒打印一次重點看 YGC 頻率和 FGC 次數(shù)如果 FGC 頻繁且每次回收不多多半是內(nèi)存泄漏或老年代太小。4.3 現(xiàn)象并發(fā)題一寫代碼就出 bug面試手寫環(huán)節(jié)翻車原因平時只看不寫對 API 的異常和邊界不熟。比如wait()必須在循環(huán)里調(diào)用、CountDownLatch.await()要處理中斷。解決把 PDF 里所有涉及手寫的題列出來每道題在 IDE 里敲一遍跑通再關掉答案重寫。重點練生產(chǎn)者消費者、單例雙重檢查、線程交替打印這三類它們覆蓋了鎖、等待通知、內(nèi)存可見性的核心。4.4 現(xiàn)象Spring 題答成配置背誦被問原理就轉(zhuǎn)移話題原因把 Spring 當黑盒用沒理解 IoC 和 AOP 的實現(xiàn)。解決寫一個最小的 IoC 容器用反射和注解實現(xiàn) bean 的掃描、實例化、注入幾十行代碼就能跑通。AOP 則用 JDK 動態(tài)代理和 CGLIB 各寫一個 Demo對比兩者的區(qū)別。參數(shù)說明JDK 動態(tài)代理要求目標類實現(xiàn)接口CGLIB 通過繼承實現(xiàn)所以 final 類無法被 CGLIB 代理這是面試常問的邊界。4.5 現(xiàn)象數(shù)據(jù)庫題只答索引原理不會看執(zhí)行計劃原因索引結(jié)構(gòu)背得熟但沒在真實查詢里用過EXPLAIN。解決建一張百萬級的模擬表對同一個查詢分別加索引和不加索引用EXPLAIN看 type、key、rows 的變化。重點理解 type 從 ALL 到 ref 到 const 的差別以及最左前綴原則在聯(lián)合索引里的體現(xiàn)。參數(shù)說明EXPLAIN的 rows 是預估掃描行數(shù)不是精確值但數(shù)量級能反映索引是否生效如果 type 是 ALL 且 rows 很大說明走了全表掃描需要檢查索引列和查詢條件是否匹配。5. 從背題到能講用費曼技巧把 PDF 榨干最后一章說一個我反復用、也確實有效的技巧把 PDF 里的每道高頻題當成你要講給一個剛?cè)胄械耐侣?。費曼技巧的核心不是復述而是用最少的術語把因果講通講不通的地方就是你的知識缺口。具體做法是挑一道題比如“ThreadLocal 為什么會內(nèi)存泄漏”先合上 PDF用白板或空白文檔寫下你的解釋然后對照三個標準檢查有沒有說清 ThreadLocalMap 的 key 是弱引用、value 是強引用有沒有說清為什么 key 弱引用還會泄漏有沒有說清remove()在什么時機調(diào)用。任何一條卡住就回去補補完再講一遍。我一般會把這種講解錄成三分鐘的語音回聽時專挑自己含糊的地方。含糊往往出現(xiàn)在兩個位置一是版本差異比如 JDK 8 和 JDK 17 在 GC 或集合實現(xiàn)上的變化二是邊界條件比如“大多數(shù)情況”和“一定”的區(qū)別。面試官追問的往往就是這兩處。下面這張表是我用來檢查講解質(zhì)量的清單每道題過一遍比刷十遍 PDF 有用。檢查項合格標準常見不合格表現(xiàn)因果鏈能說出至少三層為什么只答結(jié)論追問就重復結(jié)論版本邊界能指出 JDK 版本差異把 JDK 8 的行為當成所有版本反例能舉出一個失效場景只說“一般”“通?！眳?shù)能說出關鍵參數(shù)和默認值參數(shù)名記混或默認值說錯手寫能默寫出核心代碼結(jié)構(gòu)只記得 API 名字寫不出邏輯這個清單不是讓你逐條背而是講解時自然覆蓋。我自己的血淚經(jīng)驗是早期準備時把 PDF 刷了三遍結(jié)果面試被問“ConcurrentHashMap 的 size() 怎么實現(xiàn)的”直接卡住因為 PDF 只寫了“線程安全”沒寫 size 的實現(xiàn)細節(jié)。后來我改用講解法每道題都逼自己講到能回答“怎么實現(xiàn)的”這一層才真正穩(wěn)下來。還有一點別等到面試前一周才開始講平時每學一個模塊就講一次講完記下卡殼點那些就是你的復習重點。希望幫到你。本文還有配套的精品資源點擊獲取 Java高頻面試題PDF拆解：從背題到講清原理的實戰(zhàn)路徑
簡介這份Java高頻面試題PDF面向準備Java后端崗位面試的求職者與初中級開發(fā)者聚焦Spring生態(tài)與數(shù)據(jù)庫調(diào)優(yōu)兩大高頻考點。內(nèi)容系統(tǒng)梳理了Spring Bean生命周期實例化、依賴注入、初始化、銷毀、Spring MVC完整執(zhí)行流程、Spring Boot自動裝配原理以及SQL執(zhí)行計劃解讀、索引失效場景與優(yōu)化技巧、MySQL常見索引類型和B樹底層結(jié)構(gòu)并延伸至線程池種類與核心參數(shù)、拒絕策略等并發(fā)知識點。資源包共1個PDF文件約396KB輕量便攜適合碎片化復習與面試前速查。目前已有180人學習瀏覽。讀者可借此快速串聯(lián)Spring框架核心機制與SQL優(yōu)化思路對照執(zhí)行計劃字段與索引失效清單查漏補缺形成結(jié)構(gòu)化的面試答題框架提升技術表達與實戰(zhàn)應對能力。1. 從一份 Java 高頻面試題 PDF 說起為什么背完答案還是掛面試間里最尷尬的場景不是被問到完全沒聽過的名詞而是題目你見過、答案你背過面試官追問一句“為什么”就卡殼。很多人手里都有一份流傳的 Java 高頻面試題 PDF幾百道題、分類清晰、答案現(xiàn)成看起來是捷徑實際用起來卻像黑匣子——輸入題目、輸出答案中間的理解過程被跳過了。這份 PDF 真正該被當成什么不是背誦手冊而是一張知識地圖的索引。它告訴你哪些點會被反復考但每個點背后的原理、邊界、版本差異得自己補上。這篇文章面向正在準備 Java 后端面試的開發(fā)者尤其是工作一到三年、想從“會寫業(yè)務代碼”跨到“能講清底層機制”的人。我會把這份高頻題 PDF 拆成可復現(xiàn)的學習路徑哪些題必須手寫代碼驗證、哪些參數(shù)要親手調(diào)一遍、哪些坑是面試官最愛追問的。目標很直接——讓你下次被追問時能順著原理往下講三層而不是背完第一層就沒了。2. 把高頻題 PDF 拆成可執(zhí)行的知識模塊先分類再動手拿到一份 Java 高頻面試題 PDF第一反應不該是從第一頁開始背。我一般會先做一次結(jié)構(gòu)拆解把題目按“考察層次”重新歸類因為不同層次的題準備方式完全不同。PDF 的原始分類通常是按知識點排的——集合、并發(fā)、JVM、Spring、數(shù)據(jù)庫——但面試官提問時是混合著來的所以你得自己建一套索引。2.1 按考察層次給題目打標簽記憶層、原理層、設計層記憶層的題答案是事實性的比如“HashMap 默認容量是多少”“ArrayList 和 LinkedList 的區(qū)別”。這類題占比不小但單獨背它們性價比最低因為面試官很少只問事實一定會往原理層追。原理層的題問的是“為什么這樣設計”比如“HashMap 為什么用紅黑樹而不是 AVL”“ConcurrentHashMap 為什么在 JDK 8 改成 CAS synchronized”。設計層的題最開放比如“讓你設計一個本地緩存你會考慮哪些點”它考的是你把前面兩層串起來的能力。我的做法是給 PDF 里每道題標一個層級然后統(tǒng)計比例。如果原理層和設計層的題加起來不到一半說明這份 PDF 偏基礎你得自己補深度如果超過七成那它更適合當復習提綱而不是入門材料。這個判斷決定了你后面花多少時間在動手驗證上。2.2 用最小代碼驗證記憶層結(jié)論以 HashMap 擴容為例記憶層的結(jié)論最容易記錯也最容易被追問翻車。與其死記不如寫一段最小代碼跑一遍。下面這段代碼用來觀察 HashMap 的擴容時機和容量變化注意我加了反射讀取內(nèi)部閾值這是理解擴容邏輯的關鍵。import java.lang.reflect.Field; import java.util.HashMap; import java.util.Map; public class HashMapProbe { public static void main(String[] args) throws Exception { MapString, Integer map new HashMap(); // 反射拿到 table 和 threshold 字段觀察擴容 Field tableField HashMap.class.getDeclaredField(table); tableField.setAccessible(true); Field thresholdField HashMap.class.getDeclaredField(threshold); thresholdField.setAccessible(true); for (int i 0; i 20; i) { map.put(key i, i); Object[] table (Object[]) tableField.get(map); int threshold (int) thresholdField.get(map); int capacity table null ? 0 : table.length; System.out.printf(size%d, capacity%d, threshold%d%n, map.size(), capacity, threshold); } } }這段代碼的邏輯說明HashMap 在第一次 put 時才初始化 table默認容量 16、負載因子 0.75所以閾值是 12。當 size 超過閾值時觸發(fā)擴容容量翻倍閾值也翻倍。運行后你會看到 capacity 從 0 跳到 16再到 32threshold 從 0 到 12 再到 24。參數(shù)說明負載因子 0.75 是空間和時間的折中調(diào)大減少擴容但增加哈希沖突調(diào)小相反初始容量如果提前知道數(shù)據(jù)量應該設為預期元素數(shù) / 0.75 1避免多次擴容。這個結(jié)論背下來只要一句話但親手跑一遍面試官問“為什么是 0.75”時你就能從泊松分布和沖突概率的角度答而不是說“書上寫的”。2.3 給并發(fā)題建一張參數(shù)對照表synchronized 與 ReentrantLock并發(fā)是高頻題里最容易答得含糊的部分。我習慣把關鍵類做成對照表面試前掃一遍比背大段文字有效。下面這張表覆蓋了最常被對比的兩個鎖參數(shù)和邊界都列清楚。對比項synchronizedReentrantLock鎖獲取方式JVM 內(nèi)置自動釋放顯式 lock/unlock需 finally 釋放可中斷不支持lockInterruptibly 支持超時獲取不支持tryLock(timeout) 支持公平鎖非公平可選公平/非公平條件變量wait/notify 單一可創(chuàng)建多個 Condition鎖升級偏向鎖→輕量級→重量級無升級概念基于 AQS這張表不是讓你背而是讓你在回答時能快速定位差異點。比如面試官問“什么時候用 ReentrantLock”你就能從可中斷、超時、多條件三個場景切入而不是籠統(tǒng)說“更靈活”。參數(shù)上要特別注意ReentrantLock 的公平鎖會降低吞吐非公平鎖可能造成線程饑餓默認非公平是有性能考慮的。這些邊界在 PDF 的答案里往往只有一句話但面試官追問時就是分水嶺。3. 用 JVM 和并發(fā)兩條線串起 PDF 里的硬骨頭高頻題 PDF 里真正拉開差距的是 JVM 和并發(fā)這兩塊。它們題目多、追問深、光靠背結(jié)論必翻車。我的策略是各選一條主線把零散的題掛上去形成能自己推演的鏈條。3.1 JVM 內(nèi)存結(jié)構(gòu)從一道“對象在哪分配”追到逃逸分析PDF 里常有一道題“對象一定分配在堆上嗎”標準答案是不一定可能棧上分配。但面試官接著會問“什么情況下棧上分配”這就到了逃逸分析。要講清楚這條鏈得先理清 JVM 內(nèi)存結(jié)構(gòu)程序計數(shù)器、虛擬機棧、本地方法棧、堆、方法區(qū)JDK 8 后是元空間。對象分配的主戰(zhàn)場是堆但 JIT 編譯器在逃逸分析后可能做標量替換把對象拆成基本類型放在棧上。驗證這件事需要動手調(diào)參數(shù)。下面這組 JVM 參數(shù)用來觀察逃逸分析的效果注意-XX:PrintEscapeAnalysis在部分版本需要 debug 版 JVM生產(chǎn)環(huán)境一般用-XX:DoEscapeAnalysis開啟即可。# 開啟逃逸分析關閉標量替換做對比 java -XX:DoEscapeAnalysis -XX:-EliminateAllocations -Xmx256m -jar demo.jar # 開啟逃逸分析并允許標量替換 java -XX:DoEscapeAnalysis -XX:EliminateAllocations -Xmx256m -jar demo.jar邏輯說明DoEscapeAnalysis控制是否做逃逸分析EliminateAllocations控制是否允許標量替換。兩個都開時未逃逸的對象可能被拆散分配在棧上減少堆壓力。參數(shù)說明-Xmx256m限制堆大小方便觀察 GC 頻率變化如果對象確實逃逸了比如被返回或存入全局集合逃逸分析不會生效這時調(diào)參也沒用。常見誤用是以為開了逃逸分析所有對象就上棧實際上它只對未逃逸的局部對象生效而且受 JIT 編譯閾值影響方法得被調(diào)用足夠多次才會觸發(fā)優(yōu)化。面試時能講清“逃逸分析是 JIT 的優(yōu)化手段不是 JVM 規(guī)范強制”就已經(jīng)超過大多數(shù)候選人了。3.2 并發(fā)工具類用 CountDownLatch 和 CyclicBarrier 做對照實驗并發(fā)題里 CountDownLatch 和 CyclicBarrier 經(jīng)常被放在一起問很多人背了“一個減一個加”就完事但面試官會追問使用場景和異常處理。我一般寫兩個最小 Demo 跑一遍把行為差異刻進記憶。import java.util.concurrent.CountDownLatch; import java.util.concurrent.CyclicBarrier; import java.util.concurrent.TimeUnit; public class LatchVsBarrier { public static void main(String[] args) throws Exception { // CountDownLatch主線程等 3 個子任務完成 CountDownLatch latch new CountDownLatch(3); for (int i 0; i 3; i) { new Thread(() - { try { TimeUnit.MILLISECONDS.sleep(100); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } System.out.println(Thread.currentThread().getName() done); latch.countDown(); }).start(); } latch.await(); System.out.println(all tasks finished); // CyclicBarrier3 個線程互相等待到齊后繼續(xù) CyclicBarrier barrier new CyclicBarrier(3, () - System.out.println(barrier action executed)); for (int i 0; i 3; i) { new Thread(() - { try { System.out.println(Thread.currentThread().getName() waiting); barrier.await(); System.out.println(Thread.currentThread().getName() passed); } catch (Exception e) { Thread.currentThread().interrupt(); } }).start(); } } }邏輯說明CountDownLatch 是一次性的計數(shù)減到零后所有 await 的線程被釋放主線程繼續(xù)CyclicBarrier 是可循環(huán)的每個線程 await 后等其他人到齊然后一起繼續(xù)還能指定到齊后執(zhí)行的動作。參數(shù)說明CountDownLatch 的構(gòu)造參數(shù)是計數(shù)初始值必須和任務數(shù)一致調(diào)大了會永久阻塞CyclicBarrier 的構(gòu)造參數(shù)是參與線程數(shù)如果某個線程在 await 前拋異常其他線程會收到 BrokenBarrierException這是排查時最常忽略的點。常見誤用是把 CyclicBarrier 當 CountDownLatch 用結(jié)果發(fā)現(xiàn)它不能“一個線程等多個”因為它是互相等。面試時能說出“CyclicBarrier 的 await 會拋 BrokenBarrierException需要處理”就是加分項。3.3 線程池參數(shù)把 PDF 里的七個參數(shù)落到一次壓測里線程池的七個參數(shù)幾乎每份 PDF 都有但背下來和會調(diào)是兩回事。核心線程數(shù)、最大線程數(shù)、空閑時間、時間單位、阻塞隊列、線程工廠、拒絕策略這七個里最容易翻車的是隊列和拒絕策略的組合。我一般用一段代碼模擬任務提交觀察不同隊列下的行為。import java.util.concurrent.*; public class PoolProbe { public static void main(String[] args) { // 核心 2最大 4隊列容量 2觀察拒絕時機 ThreadPoolExecutor pool new ThreadPoolExecutor( 2, 4, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(2), Executors.defaultThreadFactory(), new ThreadPoolExecutor.AbortPolicy()); for (int i 0; i 10; i) { final int id i; try { pool.execute(() - { System.out.println(task id running on Thread.currentThread().getName()); try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); } catch (RejectedExecutionException e) { System.out.println(task id rejected); } } pool.shutdown(); } }邏輯說明任務提交時先看核心線程是否滿沒滿就新建核心線程核心滿了進隊列隊列滿了看最大線程是否滿沒滿就新建非核心線程都滿了觸發(fā)拒絕策略。參數(shù)說明ArrayBlockingQueue(2)容量為 2所以前 2 個任務占核心線程第 3、4 個進隊列第 5、6 個占最大線程第 7 個開始被拒絕。如果把隊列換成LinkedBlockingQueue無界隊列最大線程數(shù)就永遠不會被觸發(fā)任務會一直堆積直到 OOM這是生產(chǎn)環(huán)境最常見的坑。拒絕策略里 AbortPolicy 拋異常CallerRunsPolicy 讓提交線程自己跑DiscardPolicy 靜默丟棄DiscardOldestPolicy 丟最老的。面試時能說清“無界隊列會讓 maximumPoolSize 失效”比背七個參數(shù)名字有用得多。4. 避坑與排查高頻題準備里最容易翻車的五件事準備 Java 面試的過程中有些坑幾乎每個人都會踩而且踩了之后還以為是題目太難。下面這五條是我自己和身邊人反復驗證過的按“現(xiàn)象→原因→解決”寫清楚。4.1 現(xiàn)象答案背得滾瓜爛熟一追問就斷片原因記憶層和原理層混在一起背沒有建立因果鏈。PDF 的答案往往是結(jié)論式的比如“HashMap 線程不安全”但沒告訴你為什么不安全、什么場景下會出問題。解決每背一個結(jié)論強制自己問三個“為什么”然后寫最小代碼驗證。比如“線程不安全”就去跑多線程 put觀察死循環(huán)或數(shù)據(jù)丟失親手復現(xiàn)一次比背十遍都牢。4.2 現(xiàn)象JVM 參數(shù)題答得頭頭是道實際調(diào)優(yōu)時不敢下手原因參數(shù)是背的沒在真實或模擬環(huán)境里調(diào)過。比如-Xmn設多大、-XX:SurvivorRatio怎么算光看公式記不住。解決本地起一個 Spring Boot 小服務用-Xmx256m -Xmn128m跑一遍再用jstat -gc觀察 Eden、Survivor、Old 區(qū)的變化把參數(shù)和 GC 日志對應起來。參數(shù)說明jstat -gc pid 1000每秒打印一次重點看 YGC 頻率和 FGC 次數(shù)如果 FGC 頻繁且每次回收不多多半是內(nèi)存泄漏或老年代太小。4.3 現(xiàn)象并發(fā)題一寫代碼就出 bug面試手寫環(huán)節(jié)翻車原因平時只看不寫對 API 的異常和邊界不熟。比如wait()必須在循環(huán)里調(diào)用、CountDownLatch.await()要處理中斷。解決把 PDF 里所有涉及手寫的題列出來每道題在 IDE 里敲一遍跑通再關掉答案重寫。重點練生產(chǎn)者消費者、單例雙重檢查、線程交替打印這三類它們覆蓋了鎖、等待通知、內(nèi)存可見性的核心。4.4 現(xiàn)象Spring 題答成配置背誦被問原理就轉(zhuǎn)移話題原因把 Spring 當黑盒用沒理解 IoC 和 AOP 的實現(xiàn)。解決寫一個最小的 IoC 容器用反射和注解實現(xiàn) bean 的掃描、實例化、注入幾十行代碼就能跑通。AOP 則用 JDK 動態(tài)代理和 CGLIB 各寫一個 Demo對比兩者的區(qū)別。參數(shù)說明JDK 動態(tài)代理要求目標類實現(xiàn)接口CGLIB 通過繼承實現(xiàn)所以 final 類無法被 CGLIB 代理這是面試常問的邊界。4.5 現(xiàn)象數(shù)據(jù)庫題只答索引原理不會看執(zhí)行計劃原因索引結(jié)構(gòu)背得熟但沒在真實查詢里用過EXPLAIN。解決建一張百萬級的模擬表對同一個查詢分別加索引和不加索引用EXPLAIN看 type、key、rows 的變化。重點理解 type 從 ALL 到 ref 到 const 的差別以及最左前綴原則在聯(lián)合索引里的體現(xiàn)。參數(shù)說明EXPLAIN的 rows 是預估掃描行數(shù)不是精確值但數(shù)量級能反映索引是否生效如果 type 是 ALL 且 rows 很大說明走了全表掃描需要檢查索引列和查詢條件是否匹配。5. 從背題到能講用費曼技巧把 PDF 榨干最后一章說一個我反復用、也確實有效的技巧把 PDF 里的每道高頻題當成你要講給一個剛?cè)胄械耐侣?。費曼技巧的核心不是復述而是用最少的術語把因果講通講不通的地方就是你的知識缺口。具體做法是挑一道題比如“ThreadLocal 為什么會內(nèi)存泄漏”先合上 PDF用白板或空白文檔寫下你的解釋然后對照三個標準檢查有沒有說清 ThreadLocalMap 的 key 是弱引用、value 是強引用有沒有說清為什么 key 弱引用還會泄漏有沒有說清remove()在什么時機調(diào)用。任何一條卡住就回去補補完再講一遍。我一般會把這種講解錄成三分鐘的語音回聽時專挑自己含糊的地方。含糊往往出現(xiàn)在兩個位置一是版本差異比如 JDK 8 和 JDK 17 在 GC 或集合實現(xiàn)上的變化二是邊界條件比如“大多數(shù)情況”和“一定”的區(qū)別。面試官追問的往往就是這兩處。下面這張表是我用來檢查講解質(zhì)量的清單每道題過一遍比刷十遍 PDF 有用。檢查項合格標準常見不合格表現(xiàn)因果鏈能說出至少三層為什么只答結(jié)論追問就重復結(jié)論版本邊界能指出 JDK 版本差異把 JDK 8 的行為當成所有版本反例能舉出一個失效場景只說“一般”“通?！眳?shù)能說出關鍵參數(shù)和默認值參數(shù)名記混或默認值說錯手寫能默寫出核心代碼結(jié)構(gòu)只記得 API 名字寫不出邏輯這個清單不是讓你逐條背而是講解時自然覆蓋。我自己的血淚經(jīng)驗是早期準備時把 PDF 刷了三遍結(jié)果面試被問“ConcurrentHashMap 的 size() 怎么實現(xiàn)的”直接卡住因為 PDF 只寫了“線程安全”沒寫 size 的實現(xiàn)細節(jié)。后來我改用講解法每道題都逼自己講到能回答“怎么實現(xiàn)的”這一層才真正穩(wěn)下來。還有一點別等到面試前一周才開始講平時每學一個模塊就講一次講完記下卡殼點那些就是你的復習重點。希望幫到你。本文還有配套的精品資源點擊獲取