在實(shí)際 Java 高級(jí)工程師的面試中面試官常常會(huì)通過一系列精心設(shè)計(jì)的問題來考察候選人的技術(shù)深度、知識(shí)廣度以及解決復(fù)雜問題的能力。這些問題往往不是簡(jiǎn)單的 API 記憶而是圍繞 JVM、并發(fā)、框架原理、系統(tǒng)設(shè)計(jì)等核心領(lǐng)域展開的“送命題”旨在檢驗(yàn)?zāi)闶欠裾嬲斫馄浔澈蟮臋C(jī)制而不僅僅是會(huì)用。本文將圍繞一個(gè)典型的 Java 高級(jí)崗面試場(chǎng)景深入剖析面試官可能甩出的 10 道高頻筆試題不僅給出答案更會(huì)解釋其背后的原理、常見的理解誤區(qū)以及在實(shí)際項(xiàng)目中如何應(yīng)用和排查相關(guān)問題。無論你是正在準(zhǔn)備面試還是希望鞏固自己的 Java 知識(shí)體系這篇文章都將帶你進(jìn)行一次深度的技術(shù)復(fù)盤。1. JVM 內(nèi)存區(qū)域與對(duì)象創(chuàng)建過程這道題是考察 Java 基礎(chǔ)深度的經(jīng)典開場(chǎng)。面試官想確認(rèn)你是否清楚代碼在運(yùn)行時(shí)是如何被 JVM 組織和管理的。1.1 JVM 運(yùn)行時(shí)數(shù)據(jù)區(qū)詳解JVM 運(yùn)行時(shí)數(shù)據(jù)區(qū)是 Java 程序執(zhí)行的基礎(chǔ)。對(duì)于高級(jí)開發(fā)者不能只停留在“堆、棧、方法區(qū)”的名詞上必須理解每個(gè)區(qū)域的具體職責(zé)、生命周期和可能產(chǎn)生的問題。程序計(jì)數(shù)器線程私有記錄當(dāng)前線程所執(zhí)行的字節(jié)碼的行號(hào)指示器。它是唯一一個(gè)在 JVM 規(guī)范中沒有規(guī)定任何OutOfMemoryError情況的區(qū)域。Java 虛擬機(jī)棧線程私有生命周期與線程相同。每個(gè)方法執(zhí)行時(shí)都會(huì)創(chuàng)建一個(gè)棧幀用于存儲(chǔ)局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口等信息。我們常說的“棧內(nèi)存”通常指這里。如果線程請(qǐng)求的棧深度大于虛擬機(jī)所允許的深度將拋出StackOverflowError如果虛擬機(jī)?？梢詣?dòng)態(tài)擴(kuò)展但擴(kuò)展時(shí)無法申請(qǐng)到足夠內(nèi)存則拋出OutOfMemoryError。本地方法棧與虛擬機(jī)棧作用相似但服務(wù)于 Native 方法。Java 堆所有線程共享是內(nèi)存管理的核心區(qū)域幾乎所有的對(duì)象實(shí)例和數(shù)組都在這里分配內(nèi)存。是垃圾收集器管理的主要區(qū)域因此也被稱為“GC 堆”。堆內(nèi)存不足時(shí)拋出OutOfMemoryError。方法區(qū)線程共享用于存儲(chǔ)已被虛擬機(jī)加載的類型信息、常量、靜態(tài)變量、即時(shí)編譯器編譯后的代碼緩存等數(shù)據(jù)。在 HotSpot 虛擬機(jī)中方法區(qū)的具體實(shí)現(xiàn)經(jīng)歷了從“永久代”到“元空間”的演變。該區(qū)域也會(huì)發(fā)生OutOfMemoryError。運(yùn)行時(shí)常量池方法區(qū)的一部分用于存放編譯期生成的各種字面量和符號(hào)引用。一個(gè)常見的理解誤區(qū)是認(rèn)為“靜態(tài)變量在堆上”。實(shí)際上靜態(tài)變量本身作為類型數(shù)據(jù)的一部分是存儲(chǔ)在方法區(qū)元空間的。但是如果這個(gè)靜態(tài)變量是一個(gè)引用類型如static Object obj那么obj這個(gè)引用本身在方法區(qū)而obj所指向的對(duì)象實(shí)例仍然在 Java 堆中。1.2 一個(gè)對(duì)象從創(chuàng)建到消亡的全鏈路當(dāng)你在代碼中寫下new Object()時(shí)JVM 內(nèi)部發(fā)生了什么這個(gè)過程清晰地串聯(lián)了多個(gè)運(yùn)行時(shí)區(qū)域。類加載檢查當(dāng)虛擬機(jī)遇到一條new指令時(shí)首先檢查這個(gè)指令的參數(shù)是否能在常量池中定位到一個(gè)類的符號(hào)引用并檢查這個(gè)符號(hào)引用代表的類是否已被加載、解析和初始化過。如果沒有必須先執(zhí)行相應(yīng)的類加載過程。分配內(nèi)存在類加載檢查通過后虛擬機(jī)將為新生對(duì)象分配內(nèi)存。對(duì)象所需內(nèi)存大小在類加載完成后便可完全確定。分配方式有兩種指針碰撞假設(shè) Java 堆內(nèi)存是規(guī)整的用過的和空閑的內(nèi)存各在一邊中間放著一個(gè)指針作為分界點(diǎn)指示器。分配內(nèi)存就是把指針向空閑空間那邊挪動(dòng)一段與對(duì)象大小相等的距離。Serial、ParNew 等帶壓縮過程的收集器使用此方式?？臻e列表如果 Java 堆內(nèi)存不規(guī)整虛擬機(jī)需要維護(hù)一個(gè)列表記錄哪些內(nèi)存塊是可用的。分配時(shí)從列表中找到一塊足夠大的空間劃分給對(duì)象實(shí)例并更新列表記錄。CMS 這種基于標(biāo)記-清除算法的收集器采用此方式。并發(fā)安全創(chuàng)建對(duì)象是非常頻繁的操作即使只修改一個(gè)指針的位置在并發(fā)情況下也非線程安全。解決方式有兩種CAS 配上失敗重試保證更新的原子性或者本地線程分配緩沖即每個(gè)線程在堆中預(yù)先分配一小塊私有內(nèi)存TLAB線程需要分配內(nèi)存時(shí)先在 TLAB 上分配只有 TLAB 用完并分配新的 TLAB 時(shí)才需要同步鎖定。初始化零值內(nèi)存分配完成后虛擬機(jī)需要將分配到的內(nèi)存空間不包括對(duì)象頭都初始化為零值。這保證了對(duì)象的實(shí)例字段在 Java 代碼中可以不賦初始值就直接使用程序能訪問到這些字段的數(shù)據(jù)類型所對(duì)應(yīng)的零值。設(shè)置對(duì)象頭虛擬機(jī)要對(duì)對(duì)象進(jìn)行必要的設(shè)置例如這個(gè)對(duì)象是哪個(gè)類的實(shí)例、如何才能找到類的元數(shù)據(jù)信息、對(duì)象的哈希碼、對(duì)象的 GC 分代年齡等信息。這些信息存放在對(duì)象的對(duì)象頭之中。執(zhí)行init方法從虛擬機(jī)的視角看一個(gè)新的對(duì)象已經(jīng)產(chǎn)生了。但從 Java 程序的視角看對(duì)象創(chuàng)建才剛剛開始——init方法即構(gòu)造器還沒有執(zhí)行。執(zhí)行init方法按照程序員的意愿對(duì)對(duì)象進(jìn)行初始化賦值等這樣一個(gè)真正可用的對(duì)象才算完全產(chǎn)生出來。注意上述步驟 3 和 4 的順序在 JVM 規(guī)范中并未嚴(yán)格限定不同虛擬機(jī)的實(shí)現(xiàn)可能不同。對(duì)象創(chuàng)建后其生命周期就與垃圾回收機(jī)制緊密相關(guān)。對(duì)象頭中的 Mark Word 部分就包含了用于垃圾回收的標(biāo)記信息如分代年齡、鎖狀態(tài)標(biāo)志等。2. 深入理解 Java 內(nèi)存模型與 volatile 關(guān)鍵字并發(fā)編程是 Java 高級(jí)面試的必考領(lǐng)域而 Java 內(nèi)存模型是理解所有并發(fā)問題的基石。2.1 JMM 的核心主內(nèi)存與工作內(nèi)存Java 內(nèi)存模型規(guī)定了所有變量都存儲(chǔ)在主內(nèi)存中。每條線程還有自己的工作內(nèi)存線程的工作內(nèi)存中保存了被該線程使用到的變量的主內(nèi)存副本。線程對(duì)變量的所有操作都必須在工作內(nèi)存中進(jìn)行而不能直接讀寫主內(nèi)存中的變量。不同線程之間也無法直接訪問對(duì)方工作內(nèi)存中的變量線程間變量值的傳遞均需要通過主內(nèi)存來完成。這里的工作內(nèi)存并不等同于物理上的 CPU 緩存或寄存器它是 JMM 的一個(gè)抽象概念涵蓋了緩存、寫緩沖區(qū)、寄存器等。2.2 內(nèi)存間交互操作與先行發(fā)生原則JMM 定義了 8 種原子操作來完成主內(nèi)存與工作內(nèi)存的交互lock,unlock,read,load,use,assign,store,write。這些操作必須滿足一系列規(guī)則例如不允許read/load或store/write操作單獨(dú)出現(xiàn)等?！跋刃邪l(fā)生”原則是判斷數(shù)據(jù)是否存在競(jìng)爭(zhēng)、線程是否安全的主要依據(jù)。它包括程序次序規(guī)則、管程鎖定規(guī)則、volatile 變量規(guī)則、線程啟動(dòng)規(guī)則、線程終止規(guī)則、線程中斷規(guī)則、對(duì)象終結(jié)規(guī)則和傳遞性。2.3 volatile 如何保證可見性與禁止指令重排序volatile是輕量級(jí)的同步機(jī)制。它主要解決兩個(gè)問題保證可見性當(dāng)一個(gè)線程修改了一個(gè)volatile變量的值新值會(huì)立即被刷新到主內(nèi)存。并且其他線程在讀取這個(gè)變量時(shí)會(huì)使自己工作內(nèi)存中該變量的緩存行失效從而必須去主內(nèi)存重新讀取最新值。禁止指令重排序通過插入內(nèi)存屏障指令確保在volatile寫操作之前的所有操作都不會(huì)被重排序到寫之后在volatile讀操作之后的所有操作都不會(huì)被重排序到讀之前。其底層實(shí)現(xiàn)依賴于 CPU 的緩存一致性協(xié)議如 MESI和內(nèi)存屏障指令如lock前綴指令。一個(gè)經(jīng)典的volatile使用場(chǎng)景是雙重檢查鎖定實(shí)現(xiàn)單例模式public class Singleton { private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance null) { // 第一次檢查 synchronized (Singleton.class) { if (instance null) { // 第二次檢查 instance new Singleton(); } } } return instance; } }如果沒有volatileinstance new Singleton();這行代碼可能被重排序?yàn)?) 分配內(nèi)存空間2) 將引用指向內(nèi)存空間此時(shí) instance 不為 null3) 初始化對(duì)象。如果線程 A 執(zhí)行到步驟 2 后線程 B 進(jìn)入第一個(gè)if (instance null)判斷會(huì)發(fā)現(xiàn) instance 不為 null從而直接返回一個(gè)尚未初始化完成的對(duì)象導(dǎo)致錯(cuò)誤。volatile可以禁止這種重排序保證對(duì)象的初始化在引用賦值之后完成。注意volatile不保證原子性。i這種復(fù)合操作讀-改-寫即使在volatile修飾下也不是線程安全的。3. synchronized 與 ReentrantLock 的深度對(duì)比兩者都是可重入鎖但設(shè)計(jì)哲學(xué)和實(shí)現(xiàn)機(jī)制有顯著不同。3.1 實(shí)現(xiàn)機(jī)制與性能演變synchronizedJVM 層面的關(guān)鍵字通過monitorenter和monitorexit字節(jié)碼指令實(shí)現(xiàn)。鎖信息存儲(chǔ)在對(duì)象頭的 Mark Word 中。在 JDK 1.6 之前它是重量級(jí)鎖性能較差。JDK 1.6 之后進(jìn)行了大規(guī)模優(yōu)化引入了偏向鎖、輕量級(jí)鎖、重量級(jí)鎖的鎖升級(jí)機(jī)制以及鎖消除、鎖粗化等優(yōu)化手段使得其性能在大多數(shù)場(chǎng)景下與ReentrantLock相差無幾甚至更優(yōu)因?yàn)橛?JVM 自動(dòng)優(yōu)化。ReentrantLockJDK 層面實(shí)現(xiàn)的類基于AbstractQueuedSynchronizer隊(duì)列同步器。它提供了比synchronized更豐富的功能。3.2 功能特性對(duì)比特性synchronizedReentrantLock實(shí)現(xiàn)層面JVM 原生支持字節(jié)碼指令JDK API 實(shí)現(xiàn)鎖的獲取隱式獲取和釋放進(jìn)入同步塊自動(dòng)獲取退出時(shí)自動(dòng)釋放顯式調(diào)用lock()和unlock()必須在 finally 塊中釋放可中斷等待鎖的過程不可中斷支持lockInterruptibly()等待鎖時(shí)可響應(yīng)中斷公平鎖非公平鎖支持公平鎖和非公平鎖構(gòu)造函數(shù)指定條件隊(duì)列通過wait(),notify(),notifyAll()與對(duì)象監(jiān)視器配合可綁定多個(gè)Condition對(duì)象實(shí)現(xiàn)更精細(xì)的線程等待/喚醒嘗試獲取鎖不支持支持tryLock()可設(shè)置超時(shí)時(shí)間3.3 選型建議與常見誤區(qū)如何選擇優(yōu)先使用 synchronized除非你需要ReentrantLock獨(dú)有的高級(jí)功能如可中斷、超時(shí)、公平鎖、多個(gè)條件變量否則應(yīng)優(yōu)先使用synchronized。理由是其簡(jiǎn)潔、自動(dòng)釋放、由 JVM 持續(xù)優(yōu)化且不易出錯(cuò)忘記解鎖是ReentrantLock的常見錯(cuò)誤。需要高級(jí)功能時(shí)使用 ReentrantLock例如實(shí)現(xiàn)一個(gè)帶有超時(shí)獲取任務(wù)的線程池或者需要按特定順序喚醒不同等待條件的線程生產(chǎn)者-消費(fèi)者模型中可以分別喚醒生產(chǎn)者線程和消費(fèi)者線程。常見誤區(qū)誤區(qū)一ReentrantLock 一定比 synchronized 快在 JDK 1.6 的優(yōu)化下兩者在低競(jìng)爭(zhēng)場(chǎng)景下性能接近。高競(jìng)爭(zhēng)場(chǎng)景下synchronized升級(jí)為重量級(jí)鎖后性能與ReentrantLock也基本持平。性能不應(yīng)作為首要選型依據(jù)。誤區(qū)二忘記在 finally 中解鎖這是使用ReentrantLock時(shí)最危險(xiǎn)的錯(cuò)誤會(huì)導(dǎo)致死鎖。ReentrantLock lock new ReentrantLock(); lock.lock(); try { // 業(yè)務(wù)代碼 } finally { lock.unlock(); // 必須放在 finally 中確保執(zhí)行 }4. HashMap 底層原理與并發(fā)安全問題HashMap 是使用最頻繁的集合類之一其原理和線程安全性是面試高頻點(diǎn)。4.1 JDK 1.8 前后的結(jié)構(gòu)演變JDK 1.7 及之前數(shù)組 鏈表。當(dāng)發(fā)生哈希沖突時(shí)采用頭插法將新元素插入鏈表頭部。JDK 1.8 及之后數(shù)組 鏈表 / 紅黑樹。當(dāng)鏈表長(zhǎng)度超過閾值默認(rèn)為 8且數(shù)組長(zhǎng)度大于等于 64 時(shí)鏈表會(huì)轉(zhuǎn)換為紅黑樹以提升查找效率從 O(n) 提升到 O(log n)。當(dāng)樹節(jié)點(diǎn)數(shù)小于 6 時(shí)會(huì)退化為鏈表。插入元素改用尾插法。4.2 關(guān)鍵參數(shù)與擴(kuò)容機(jī)制容量數(shù)組的長(zhǎng)度必須是 2 的冪。默認(rèn)初始容量為 16。負(fù)載因子默認(rèn)為 0.75。它決定了 HashMap 在擴(kuò)容前可以達(dá)到多滿。當(dāng)元素?cái)?shù)量 容量 * 負(fù)載因子時(shí)觸發(fā)擴(kuò)容。擴(kuò)容創(chuàng)建一個(gè)新的數(shù)組容量為原來的 2 倍然后重新計(jì)算所有元素在新數(shù)組中的位置rehash。這是一個(gè)耗時(shí)的操作。JDK 1.8 優(yōu)化了 rehash 過程元素的新位置要么是原索引位置要么是原索引 舊容量。為什么容量是 2 的冪為了高效計(jì)算元素在數(shù)組中的索引index hash (capacity - 1)。當(dāng)容量為 2 的冪時(shí)capacity - 1的二進(jìn)制形式是全 1如 15 是 1111這使得按位與操作的結(jié)果等同于hash % capacity但位運(yùn)算的效率遠(yuǎn)高于取模運(yùn)算。4.3 線程不安全的表現(xiàn)與替代方案HashMap 在并發(fā)環(huán)境下進(jìn)行 put 操作可能引發(fā)死循環(huán)JDK 1.7 頭插法導(dǎo)致鏈表成環(huán)、數(shù)據(jù)丟失等問題。其內(nèi)部實(shí)現(xiàn)沒有同步措施。線程安全的替代方案Hashtable全表方法使用synchronized修飾性能差不推薦。Collections.synchronizedMap包裝一個(gè)普通的 Map所有方法加鎖性能一般。ConcurrentHashMap首選方案。JDK 1.7 采用分段鎖SegmentJDK 1.8 改為synchronized鎖桶鏈表頭/樹根 CAS的實(shí)現(xiàn)方式大大提升了并發(fā)度。ConcurrentHashMap 在 JDK 1.8 中的 put 流程簡(jiǎn)述計(jì)算 key 的 hash。如果 table 為空則初始化。如果定位到的桶為空使用 CAS 嘗試寫入失敗則自旋保證成功。如果桶不為空hash MOVED說明正在擴(kuò)容則幫助擴(kuò)容。如果桶不為空則使用synchronized鎖住桶的頭節(jié)點(diǎn)鏈表或樹進(jìn)行插入或更新操作。如果鏈表長(zhǎng)度超過閾值則轉(zhuǎn)換為紅黑樹。最后檢查容量決定是否擴(kuò)容。5. Spring 框架中 Bean 的生命周期理解 Bean 的生命周期是掌握 Spring 框架核心機(jī)制的關(guān)鍵它串聯(lián)了 IOC 容器、AOP、事務(wù)管理等諸多功能。5.1 一個(gè) Bean 從誕生到銷毀的完整旅程對(duì)于普通的 Singleton Bean其生命周期大致如下實(shí)例化容器通過反射調(diào)用構(gòu)造器創(chuàng)建 Bean 的實(shí)例。屬性賦值為 Bean 的屬性注入值依賴注入。BeanNameAware.setBeanName如果 Bean 實(shí)現(xiàn)了BeanNameAware接口則調(diào)用其setBeanName方法傳入 Bean 的 ID。BeanFactoryAware.setBeanFactory如果 Bean 實(shí)現(xiàn)了BeanFactoryAware接口則調(diào)用其setBeanFactory方法傳入當(dāng)前的 BeanFactory。ApplicationContextAware.setApplicationContext如果 Bean 實(shí)現(xiàn)了ApplicationContextAware接口則調(diào)用其setApplicationContext方法傳入當(dāng)前的 ApplicationContext。BeanPostProcessor.postProcessBeforeInitialization所有BeanPostProcessor的postProcessBeforeInitialization方法被調(diào)用。PostConstruct 或 InitializingBean.afterPropertiesSet如果 Bean 使用了PostConstruct注解或者實(shí)現(xiàn)了InitializingBean接口則執(zhí)行對(duì)應(yīng)的初始化方法。自定義 init-method如果在 Bean 定義中指定了init-method則執(zhí)行該方法。BeanPostProcessor.postProcessAfterInitialization所有BeanPostProcessor的postProcessAfterInitialization方法被調(diào)用。AOP 代理對(duì)象的生成通常發(fā)生在這個(gè)階段。Bean 就緒此時(shí) Bean 已經(jīng)完全初始化可以被應(yīng)用程序使用。容器關(guān)閉當(dāng) ApplicationContext 被關(guān)閉時(shí)。PreDestroy 或 DisposableBean.destroy如果 Bean 使用了PreDestroy注解或者實(shí)現(xiàn)了DisposableBean接口則執(zhí)行對(duì)應(yīng)的銷毀方法。自定義 destroy-method如果在 Bean 定義中指定了destroy-method則執(zhí)行該方法。5.2 BeanPostProcessor 與 AOP 代理創(chuàng)建BeanPostProcessor是 Spring 提供的一個(gè)強(qiáng)大的擴(kuò)展點(diǎn)。它允許在 Bean 初始化前后進(jìn)行自定義處理。Spring 自身的很多功能如Autowired注解的處理、AOP 動(dòng)態(tài)代理的創(chuàng)建都是通過內(nèi)置的BeanPostProcessor實(shí)現(xiàn)的。AOP 代理的創(chuàng)建時(shí)機(jī)通常是在BeanPostProcessor.postProcessAfterInitialization階段。容器會(huì)檢查當(dāng)前 Bean 是否需要被代理即是否匹配切點(diǎn)表達(dá)式如果需要?jiǎng)t會(huì)用 JDK 動(dòng)態(tài)代理或 CGLIB 生成一個(gè)代理對(duì)象并返回這個(gè)代理對(duì)象替代原始 Bean。這就是為什么我們Autowired注入的實(shí)際上是一個(gè)代理對(duì)象。5.3 循環(huán)依賴的解決原理Spring 默認(rèn)支持單例模式下的屬性注入Setter/Field循環(huán)依賴但不支持構(gòu)造器注入的循環(huán)依賴。其解決原理依賴于三級(jí)緩存一級(jí)緩存 singletonObjects存放完全初始化好的 Bean。二級(jí)緩存 earlySingletonObjects存放提前暴露的、尚未完成屬性注入和初始化的 Bean早期引用。三級(jí)緩存 singletonFactories存放 Bean 工廠對(duì)象用于生成早期引用。解決流程以 A 依賴 BB 依賴 A 為例創(chuàng)建 A實(shí)例化后將 A 的工廠對(duì)象放入三級(jí)緩存。為 A 注入屬性 B發(fā)現(xiàn) B 不存在開始創(chuàng)建 B。創(chuàng)建 B實(shí)例化后將 B 的工廠對(duì)象放入三級(jí)緩存。為 B 注入屬性 A從一級(jí)緩存未找到 A但從三級(jí)緩存找到了 A 的工廠對(duì)象。工廠對(duì)象生成 A 的早期引用可能是原始對(duì)象也可能是代理對(duì)象并將其放入二級(jí)緩存同時(shí)從三級(jí)緩存移除。B 成功獲得 A 的早期引用完成屬性注入和初始化成為一個(gè)完整的 Bean放入一級(jí)緩存并清理二、三級(jí)緩存?；氐?A 的創(chuàng)建流程此時(shí)可以從一級(jí)緩存直接拿到完整的 B完成 A 的屬性注入和初始化。A 完成后也放入一級(jí)緩存。注意原型Prototype作用域的 Bean 不支持循環(huán)依賴因?yàn)?Spring 不緩存原型 Bean。6. 數(shù)據(jù)庫事務(wù)隔離級(jí)別與 Spring 事務(wù)傳播行為這是連接數(shù)據(jù)庫理論與 Spring 實(shí)踐的核心問題。6.1 數(shù)據(jù)庫事務(wù)的四大特性與隔離級(jí)別ACID原子性事務(wù)是一個(gè)不可分割的工作單位。一致性事務(wù)執(zhí)行前后數(shù)據(jù)庫從一個(gè)一致性狀態(tài)變換到另一個(gè)一致性狀態(tài)。隔離性多個(gè)并發(fā)事務(wù)之間互不干擾。持久性事務(wù)一旦提交對(duì)數(shù)據(jù)的改變是永久性的。隔離級(jí)別為了解決并發(fā)問題讀未提交一個(gè)事務(wù)可以讀到另一個(gè)事務(wù)未提交的數(shù)據(jù)。存在臟讀、不可重復(fù)讀、幻讀問題。讀已提交一個(gè)事務(wù)只能讀到另一個(gè)事務(wù)已提交的數(shù)據(jù)。解決了臟讀但存在不可重復(fù)讀、幻讀問題。這是 Oracle 的默認(rèn)級(jí)別。可重復(fù)讀一個(gè)事務(wù)執(zhí)行過程中看到的數(shù)據(jù)總是跟這個(gè)事務(wù)啟動(dòng)時(shí)看到的數(shù)據(jù)是一致的。解決了臟讀和不可重復(fù)讀但存在幻讀問題。這是 MySQL InnoDB 的默認(rèn)級(jí)別通過 MVCC 和間隙鎖在一定程度上解決了幻讀。串行化所有事務(wù)串行執(zhí)行。解決了所有并發(fā)問題但性能最差。6.2 Spring 事務(wù)的七種傳播行為傳播行為定義了在多個(gè)事務(wù)方法相互調(diào)用時(shí)事務(wù)應(yīng)該如何傳播。傳播行為類型說明外部存在事務(wù)外部不存在事務(wù)REQUIRED(默認(rèn))支持當(dāng)前事務(wù)如果不存在則新建一個(gè)。加入當(dāng)前事務(wù)。新建一個(gè)事務(wù)。SUPPORTS支持當(dāng)前事務(wù)如果不存在則以非事務(wù)方式執(zhí)行。加入當(dāng)前事務(wù)。以非事務(wù)方式執(zhí)行。MANDATORY支持當(dāng)前事務(wù)如果不存在則拋出異常。加入當(dāng)前事務(wù)。拋出IllegalTransactionStateException。REQUIRES_NEW新建事務(wù)如果當(dāng)前存在事務(wù)則掛起當(dāng)前事務(wù)。掛起當(dāng)前事務(wù)新建獨(dú)立事務(wù)。新建一個(gè)事務(wù)。NOT_SUPPORTED以非事務(wù)方式執(zhí)行如果當(dāng)前存在事務(wù)則掛起當(dāng)前事務(wù)。掛起當(dāng)前事務(wù)以非事務(wù)方式執(zhí)行。以非事務(wù)方式執(zhí)行。NEVER以非事務(wù)方式執(zhí)行如果當(dāng)前存在事務(wù)則拋出異常。拋出IllegalTransactionStateException。以非事務(wù)方式執(zhí)行。NESTED如果當(dāng)前存在事務(wù)則在嵌套事務(wù)內(nèi)執(zhí)行如果不存在則同 REQUIRED。在嵌套事務(wù)保存點(diǎn)內(nèi)執(zhí)行。外層回滾會(huì)導(dǎo)致內(nèi)層回滾內(nèi)層回滾不影響外層。新建一個(gè)事務(wù)。常見使用場(chǎng)景REQUIRED最常用適用于大多數(shù)業(yè)務(wù)方法。REQUIRES_NEW用于日志記錄、消息發(fā)送等獨(dú)立操作即使主業(yè)務(wù)失敗這些操作也需要提交。NESTED用于可獨(dú)立回滾的子業(yè)務(wù)例如一個(gè)訂單處理流程中扣減庫存和生成物流單可以放在嵌套事務(wù)中如果生成物流單失敗可以只回滾這部分而不影響庫存扣減。6.3 Transactional 失效的常見場(chǎng)景方法非 publicTransactional只能用于 public 方法上在 protected、private 或默認(rèn)可見性的方法上使用事務(wù)不會(huì)生效。自調(diào)用問題在同一個(gè)類中一個(gè)非事務(wù)方法 A 調(diào)用一個(gè)Transactional方法 B事務(wù)不會(huì)生效。因?yàn)?Spring 的事務(wù)管理基于 AOP 代理自調(diào)用時(shí)走的是this指針而不是代理對(duì)象。Service public class OrderService { public void createOrder() { // 自調(diào)用事務(wù)失效 this.deductStock(); } Transactional public void deductStock() { // ... } }異常類型未被捕獲默認(rèn)情況下Transactional只在拋出RuntimeException和Error時(shí)回滾。如果拋出的是受檢異常如IOException事務(wù)不會(huì)回滾?？梢酝ㄟ^Transactional(rollbackFor Exception.class)來指定。異常被捕獲如果在方法內(nèi)部用try-catch捕獲了異常但沒有重新拋出事務(wù)也不會(huì)回滾。數(shù)據(jù)庫引擎不支持例如 MySQL 的 MyISAM 引擎不支持事務(wù)。7. Redis 持久化機(jī)制 RDB 與 AOF 的抉擇Redis 作為內(nèi)存數(shù)據(jù)庫持久化是保證數(shù)據(jù)安全的關(guān)鍵。RDB 和 AOF 是兩種核心機(jī)制各有優(yōu)劣。7.1 RDB快照持久化RDB 在指定的時(shí)間間隔內(nèi)生成數(shù)據(jù)集的時(shí)間點(diǎn)快照。觸發(fā)方式手動(dòng)觸發(fā)執(zhí)行SAVE阻塞或BGSAVE后臺(tái)異步命令。自動(dòng)觸發(fā)在配置文件中設(shè)置save seconds changes例如save 900 1表示 900 秒內(nèi)至少有 1 個(gè) key 被修改則觸發(fā) BGSAVE。優(yōu)點(diǎn)文件緊湊適合備份和災(zāi)難恢復(fù)。恢復(fù)大數(shù)據(jù)集時(shí)速度比 AOF 快。最大化 Redis 性能因?yàn)楦高M(jìn)程只需 fork 一個(gè)子進(jìn)程來持久化父進(jìn)程繼續(xù)處理命令。缺點(diǎn)會(huì)丟失最后一次快照之后的所有數(shù)據(jù)取決于備份周期。fork()子進(jìn)程時(shí)如果數(shù)據(jù)集很大可能會(huì)阻塞主進(jìn)程盡管時(shí)間很短。7.2 AOF追加日志持久化AOF 記錄服務(wù)器執(zhí)行的所有寫操作命令并在服務(wù)器啟動(dòng)時(shí)通過重新執(zhí)行這些命令來還原數(shù)據(jù)集。同步策略通過appendfsync配置always每個(gè)寫命令都同步到磁盤。數(shù)據(jù)最安全性能最差。everysec每秒同步一次。是默認(rèn)策略在安全性和性能之間取得平衡。no由操作系統(tǒng)決定何時(shí)同步。性能最好但數(shù)據(jù)丟失風(fēng)險(xiǎn)最高。優(yōu)點(diǎn)數(shù)據(jù)安全性更高最多丟失一秒的數(shù)據(jù)使用 everysec。AOF 文件易于理解和解析。缺點(diǎn)文件體積通常比 RDB 大?；謴?fù)速度比 RDB 慢。在寫負(fù)載高時(shí)對(duì)性能的影響比 RDB 大。7.3 混合持久化與生產(chǎn)環(huán)境建議Redis 4.0 引入了混合持久化。開啟后AOF 重寫時(shí)不再是單純將當(dāng)前數(shù)據(jù)集轉(zhuǎn)換為 AOF 命令而是將重寫這一刻之前的內(nèi)存數(shù)據(jù)以 RDB 格式寫入 AOF 文件頭部之后的新增命令繼續(xù)以 AOF 格式追加。這樣結(jié)合了 RDB 的快速加載和 AOF 的增量數(shù)據(jù)安全。生產(chǎn)環(huán)境配置建議同時(shí)開啟 RDB 和 AOF用 AOF 保證數(shù)據(jù)安全用 RDB 做冷備和快速恢復(fù)。AOF 策略設(shè)置為appendfsync everysec。合理設(shè)置 RDB 觸發(fā)條件例如save 900 1、save 300 10、save 60 10000。監(jiān)控fork耗時(shí)如果數(shù)據(jù)集很大fork操作可能成為瓶頸。定期檢查 AOF 文件大小并在低峰期手動(dòng)觸發(fā)BGREWRITEAOF進(jìn)行重寫或設(shè)置自動(dòng)重寫條件auto-aof-rewrite-percentage和auto-aof-rewrite-min-size。8. 分布式系統(tǒng) CAP 理論與 BASE 理論這是分布式系統(tǒng)設(shè)計(jì)的理論基礎(chǔ)理解它們才能做出合理的架構(gòu)選型。8.1 CAP 定理的內(nèi)涵與權(quán)衡CAP 定理指出一個(gè)分布式系統(tǒng)不可能同時(shí)滿足一致性、可用性和分區(qū)容錯(cuò)性最多只能同時(shí)滿足其中兩項(xiàng)。一致性所有節(jié)點(diǎn)在同一時(shí)間看到的數(shù)據(jù)是完全相同的強(qiáng)一致性?？捎眯悦總€(gè)請(qǐng)求都能收到一個(gè)非錯(cuò)誤的響應(yīng)但不保證數(shù)據(jù)是最新的。分區(qū)容錯(cuò)性系統(tǒng)在遇到網(wǎng)絡(luò)分區(qū)節(jié)點(diǎn)間無法通信時(shí)仍然能夠繼續(xù)提供服務(wù)。網(wǎng)絡(luò)分區(qū)是分布式系統(tǒng)必須面對(duì)的現(xiàn)實(shí)因此 P 是必須保障的。于是實(shí)際的選擇就變成了CP 還是 AP。CP 系統(tǒng)當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)時(shí)為了保證一致性系統(tǒng)可能拒絕部分請(qǐng)求從而犧牲了可用性。例如 ZooKeeper、Etcd。AP 系統(tǒng)當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)時(shí)系統(tǒng)繼續(xù)提供服務(wù)但不同分區(qū)之間的數(shù)據(jù)可能不一致犧牲了一致性。例如 Eureka、Cassandra。8.2 BASE 理論對(duì) CAP 中一致性和可用性權(quán)衡的結(jié)果BASE 理論是對(duì) CAP 中一致性和可用性權(quán)衡的一種實(shí)踐方案其核心思想是即使無法做到強(qiáng)一致性但系統(tǒng)可以采用適當(dāng)?shù)姆绞竭_(dá)到最終一致性?；究捎孟到y(tǒng)在出現(xiàn)不可預(yù)知故障時(shí)允許損失部分可用性如響應(yīng)時(shí)間變長(zhǎng)、功能降級(jí)。軟狀態(tài)允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)并認(rèn)為該狀態(tài)不影響系統(tǒng)的整體可用性。最終一致性經(jīng)過一段時(shí)間后所有數(shù)據(jù)副本最終會(huì)達(dá)到一致的狀態(tài)。BASE 理論面向的是高可用、可擴(kuò)展的分布式系統(tǒng)與 ACID 強(qiáng)調(diào)的強(qiáng)一致性相對(duì)。互聯(lián)網(wǎng)系統(tǒng)大多遵循 BASE 理論。8.3 在常見中間件中的體現(xiàn)ZooKeeper (CP)作為分布式協(xié)調(diào)服務(wù)強(qiáng)一致性是其核心。當(dāng) Leader 宕機(jī)或網(wǎng)絡(luò)分區(qū)時(shí)會(huì)進(jìn)行選舉在此期間服務(wù)不可用。Eureka (AP)作為服務(wù)注冊(cè)中心高可用是關(guān)鍵。節(jié)點(diǎn)間通過異步復(fù)制同步數(shù)據(jù)允許在短時(shí)間內(nèi)各節(jié)點(diǎn)數(shù)據(jù)不一致但能保證服務(wù)注冊(cè)與發(fā)現(xiàn)的基本可用。Redis Cluster (AP)默認(rèn)情況下當(dāng)主節(jié)點(diǎn)故障且無法完成故障轉(zhuǎn)移時(shí)集群仍然可以處理請(qǐng)求可能讀到舊數(shù)據(jù)或?qū)懭胧?yōu)先保證可用性?？梢酝ㄟ^配置cluster-require-full-coverage調(diào)整為更偏向 CP。MySQL 主從 (AP)默認(rèn)的異步復(fù)制是 AP 模型。半同步復(fù)制可以提升一致性但嚴(yán)格來說也不是強(qiáng)一致。9. 消息隊(duì)列如何保證消息不丟失消息不丟失是消息隊(duì)列可靠性的核心需要從生產(chǎn)者、Broker、消費(fèi)者三個(gè)環(huán)節(jié)來保障。9.1 生產(chǎn)端可靠性投遞確保消息成功發(fā)送到 Broker。事務(wù)消息像 RocketMQ 提供的事務(wù)消息機(jī)制通過兩階段提交保證本地事務(wù)與消息發(fā)送的原子性。確認(rèn)機(jī)制使用 RabbitMQ 的publisher confirm機(jī)制或 Kafka 的acks參數(shù)。Kafka 中acksall表示所有 ISR 副本都確認(rèn)收到消息可靠性最高。RabbitMQ 中將信道設(shè)置為confirm模式每條消息都會(huì)異步返回一個(gè)ack或nack。本地消息表在業(yè)務(wù)數(shù)據(jù)庫中維護(hù)一張消息發(fā)送表將消息發(fā)送和業(yè)務(wù)操作放在同一個(gè)本地事務(wù)中。然后有一個(gè)定時(shí)任務(wù)掃描此表將未發(fā)送的消息重新投遞到 MQ。這是一種最終一致性方案。失敗重試發(fā)送失敗后進(jìn)行有限次數(shù)的重試并配合指數(shù)退避策略。9.2 Broker 端持久化與高可用確保消息在 Broker 上安全存儲(chǔ)不因 Broker 宕機(jī)而丟失。持久化配置RabbitMQ將隊(duì)列和消息都設(shè)置為持久化durabletrue和delivery_mode2。Kafka通過replication.factor設(shè)置副本數(shù)通常 3通過min.insync.replicas設(shè)置最小同步副本數(shù)例如 2。生產(chǎn)者使用acksall。集群與高可用采用多節(jié)點(diǎn)集群如 RabbitMQ 的鏡像隊(duì)列、Kafka 的分區(qū)多副本機(jī)制確保單點(diǎn)故障時(shí)數(shù)據(jù)不丟失且服務(wù)可用。9.3 消費(fèi)端可靠處理確保消息被消費(fèi)者成功處理。手動(dòng)確認(rèn)關(guān)閉自動(dòng)確認(rèn)在處理完業(yè)務(wù)邏輯后手動(dòng)向 Broker 發(fā)送ack。如果處理失敗或異常則發(fā)送nack讓消息重新入隊(duì)或進(jìn)入死信隊(duì)列。// RabbitMQ 示例 channel.basicConsume(queueName, false, deliverCallback, cancelCallback); // ... 業(yè)務(wù)處理 channel.basicAck(deliveryTag, false); // 手動(dòng)確認(rèn)冪等性設(shè)計(jì)由于網(wǎng)絡(luò)重傳或消費(fèi)者重啟可能導(dǎo)致消息被重復(fù)消費(fèi)消費(fèi)者端的業(yè)務(wù)邏輯必須支持冪等。常見方法有利用數(shù)據(jù)庫唯一約束如訂單號(hào)。在 Redis 中維護(hù)已處理消息的 ID需設(shè)置過期時(shí)間。使用樂觀鎖如update table set status processed where id ? and status unprocessed。死信隊(duì)列將重試多次仍失敗的消息轉(zhuǎn)移到死信隊(duì)列進(jìn)行人工干預(yù)或后續(xù)處理避免消息堆積影響正常消費(fèi)。一個(gè)完整的保障鏈路是生產(chǎn)端確認(rèn) Broker 持久化與副本 消費(fèi)端手動(dòng)確認(rèn)與冪等。10. 設(shè)計(jì)一個(gè)短鏈接生成系統(tǒng)這道題考察系統(tǒng)設(shè)計(jì)能力需要從功能、性能、存儲(chǔ)、算法等多方面考慮。10.1 核心需求與設(shè)計(jì)目標(biāo)功能將長(zhǎng) URL 轉(zhuǎn)換為短 URL訪問短 URL 時(shí)重定向到原始長(zhǎng) URL。性能生成和重定向速度要快QPS 高。可用性服務(wù)需要高可用短鏈接不能失效。容量短鏈接要足夠短且能支持海量映射。安全性避免短鏈接被猜解或?yàn)E用。10.2 短鏈接生成算法這是系統(tǒng)的核心。常見方案有自增 ID 進(jìn)制轉(zhuǎn)換使用分布式 ID 生成器如 Snowflake生成一個(gè)全局唯一的自增 ID然后將這個(gè)十進(jìn)制 ID 轉(zhuǎn)換為 62 進(jìn)制a-zA-Z0-9得到短碼。優(yōu)點(diǎn)是簡(jiǎn)單、無碰撞缺點(diǎn)是短碼長(zhǎng)度不固定且可能被推測(cè)出業(yè)務(wù)量。Hash 算法對(duì)長(zhǎng) URL 進(jìn)行 MD5 或 MurmurHash 計(jì)算取哈希值的前若干位作為短碼。優(yōu)點(diǎn)是長(zhǎng)度固定缺點(diǎn)是存在哈希沖突需要解決。解決沖突如果發(fā)生沖突可以在原 URL 后附加一個(gè)隨機(jī)鹽值重新計(jì)算哈希或者使用布隆過濾器預(yù)先判斷。推薦方案對(duì)于一般系統(tǒng)使用Snowflake 生成 ID 62 進(jìn)制轉(zhuǎn)換是平衡復(fù)雜度和性能的好選擇。對(duì)于要求短碼長(zhǎng)度固定且不可預(yù)測(cè)的場(chǎng)景可以考慮使用Hash 算法 沖突檢測(cè)與重試。10.3 系統(tǒng)架構(gòu)與組件設(shè)計(jì)服務(wù)層生成服務(wù)接收長(zhǎng) URL通過算法生成短碼將映射關(guān)系持久化返回短 URL。重定向服務(wù)接收短碼查詢對(duì)應(yīng)的長(zhǎng) URL返回 302 重定向響應(yīng)。存儲(chǔ)層關(guān)系型數(shù)據(jù)庫存儲(chǔ)id, short_code, long_url, created_at等。需要為short_code建立唯一索引。緩存使用 Redis 存儲(chǔ)short_code - long_url的映射加速重定向查詢。緩存策略可以是永久存儲(chǔ)或設(shè)置較長(zhǎng) TTL。關(guān)鍵流程生成流程用戶提交長(zhǎng) URL。可選先查緩存或庫看是否已存在該長(zhǎng) URL 的短碼防重復(fù)。調(diào)用 ID 生成器獲取唯一 ID。將 ID 轉(zhuǎn)換為 62 進(jìn)制短碼。將(短碼, 長(zhǎng) URL)寫入數(shù)據(jù)庫和緩存。返回短 URL如http://short.com/abc123。重定向流程用戶訪問短 URL。Nginx 等網(wǎng)關(guān)層解析出短碼。首先查詢 Redis 緩存。若緩存未命中查詢數(shù)據(jù)庫。若數(shù)據(jù)庫命中將長(zhǎng) URL 寫回緩存并返回 302 重定向響應(yīng)。若未命中返回 404。10.4 擴(kuò)展考慮與優(yōu)化自定義短碼允許用戶自定義短碼需要檢查唯一性。過期與清理可以為短鏈接設(shè)置 TTL定期清理過期數(shù)據(jù)。訪問統(tǒng)計(jì)在重定向時(shí)異步記錄訪問日志用于統(tǒng)計(jì)點(diǎn)擊量、來源等。防惡意攻擊限制同一 IP 的生成頻率使用驗(yàn)證碼等。分庫分表當(dāng)數(shù)據(jù)量極大時(shí)可以根據(jù)短碼進(jìn)行分片。高可用服務(wù)無狀態(tài)化方便水平擴(kuò)展。數(shù)據(jù)庫主從緩存集群。通過這 10 個(gè)問題的深度剖析我們可以看到Java 高級(jí)面試考察的是對(duì)技術(shù)原理的透徹理解、對(duì)生產(chǎn)實(shí)踐的經(jīng)驗(yàn)積累以及解決復(fù)雜問題的系統(tǒng)化思維。掌握這些知識(shí)不僅是為了通過面試更是為了在實(shí)際工作中能夠設(shè)計(jì)出更穩(wěn)健的系統(tǒng)更高效地排查和解決問題。建議在理解上述原理的基礎(chǔ)上結(jié)合源碼閱讀和實(shí)際項(xiàng)目經(jīng)驗(yàn)形成自己的知識(shí)體系和判斷力。