在實(shí)際 Java 高級工程師的面試中面試官常常會(huì)通過一系列精心設(shè)計(jì)的問題來考察候選人的技術(shù)深度、知識廣度以及解決復(fù)雜問題的能力。這些問題往往不是簡單的 API 記憶而是圍繞 JVM、并發(fā)、框架原理、系統(tǒng)設(shè)計(jì)等核心領(lǐng)域展開的“送命題”旨在檢驗(yàn)?zāi)闶欠裾嬲斫馄浔澈蟮臋C(jī)制而不僅僅是會(huì)用。本文將圍繞一個(gè)典型的 Java 高級崗面試場景深入剖析面試官可能甩出的 10 道高頻筆試題不僅給出答案更會(huì)解釋其背后的原理、常見的理解誤區(qū)以及在實(shí)際項(xiàng)目中如何應(yīng)用和排查相關(guān)問題。無論你是正在準(zhǔn)備面試還是希望鞏固自己的 Java 知識體系這篇文章都將帶你進(jìn)行一次深度的技術(shù)復(fù)盤。1. JVM 內(nèi)存區(qū)域與對象創(chuàng)建過程這道題是考察 Java 基礎(chǔ)深度的經(jī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ǔ)。對于高級開發(fā)者不能只停留在“堆、棧、方法區(qū)”的名詞上必須理解每個(gè)區(qū)域的具體職責(zé)、生命周期和可能產(chǎn)生的問題。程序計(jì)數(shù)器線程私有記錄當(dāng)前線程所執(zhí)行的字節(jié)碼的行號指示器。它是唯一一個(gè)在 JVM 規(guī)范中沒有規(guī)定任何OutOfMemoryError情況的區(qū)域。Java 虛擬機(jī)棧線程私有生命周期與線程相同。每個(gè)方法執(zhí)行時(shí)都會(huì)創(chuàng)建一個(gè)棧幀用于存儲(chǔ)局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口等信息。我們常說的“棧內(nèi)存”通常指這里。如果線程請求的棧深度大于虛擬機(jī)所允許的深度將拋出StackOverflowError如果虛擬機(jī)?？梢詣?dòng)態(tài)擴(kuò)展但擴(kuò)展時(shí)無法申請到足夠內(nèi)存則拋出OutOfMemoryError。本地方法棧與虛擬機(jī)棧作用相似但服務(wù)于 Native 方法。Java 堆所有線程共享是內(nèi)存管理的核心區(qū)域幾乎所有的對象實(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ū)的一部分用于存放編譯期生成的各種字面量和符號引用。一個(gè)常見的理解誤區(qū)是認(rèn)為“靜態(tài)變量在堆上”。實(shí)際上靜態(tài)變量本身作為類型數(shù)據(jù)的一部分是存儲(chǔ)在方法區(qū)元空間的。但是如果這個(gè)靜態(tài)變量是一個(gè)引用類型如static Object obj那么obj這個(gè)引用本身在方法區(qū)而obj所指向的對象實(shí)例仍然在 Java 堆中。1.2 一個(gè)對象從創(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è)類的符號引用并檢查這個(gè)符號引用代表的類是否已被加載、解析和初始化過。如果沒有必須先執(zhí)行相應(yīng)的類加載過程。分配內(nèi)存在類加載檢查通過后虛擬機(jī)將為新生對象分配內(nèi)存。對象所需內(nèi)存大小在類加載完成后便可完全確定。分配方式有兩種指針碰撞假設(shè) Java 堆內(nèi)存是規(guī)整的用過的和空閑的內(nèi)存各在一邊中間放著一個(gè)指針作為分界點(diǎn)指示器。分配內(nèi)存就是把指針向空閑空間那邊挪動(dòng)一段與對象大小相等的距離。Serial、ParNew 等帶壓縮過程的收集器使用此方式?？臻e列表如果 Java 堆內(nèi)存不規(guī)整虛擬機(jī)需要維護(hù)一個(gè)列表記錄哪些內(nèi)存塊是可用的。分配時(shí)從列表中找到一塊足夠大的空間劃分給對象實(shí)例并更新列表記錄。CMS 這種基于標(biāo)記-清除算法的收集器采用此方式。并發(fā)安全創(chuàng)建對象是非常頻繁的操作即使只修改一個(gè)指針的位置在并發(fā)情況下也非線程安全。解決方式有兩種CAS 配上失敗重試保證更新的原子性或者本地線程分配緩沖即每個(gè)線程在堆中預(yù)先分配一小塊私有內(nèi)存TLAB線程需要分配內(nèi)存時(shí)先在 TLAB 上分配只有 TLAB 用完并分配新的 TLAB 時(shí)才需要同步鎖定。初始化零值內(nèi)存分配完成后虛擬機(jī)需要將分配到的內(nèi)存空間不包括對象頭都初始化為零值。這保證了對象的實(shí)例字段在 Java 代碼中可以不賦初始值就直接使用程序能訪問到這些字段的數(shù)據(jù)類型所對應(yīng)的零值。設(shè)置對象頭虛擬機(jī)要對對象進(jìn)行必要的設(shè)置例如這個(gè)對象是哪個(gè)類的實(shí)例、如何才能找到類的元數(shù)據(jù)信息、對象的哈希碼、對象的 GC 分代年齡等信息。這些信息存放在對象的對象頭之中。執(zhí)行init方法從虛擬機(jī)的視角看一個(gè)新的對象已經(jīng)產(chǎn)生了。但從 Java 程序的視角看對象創(chuàng)建才剛剛開始——init方法即構(gòu)造器還沒有執(zhí)行。執(zhí)行init方法按照程序員的意愿對對象進(jìn)行初始化賦值等這樣一個(gè)真正可用的對象才算完全產(chǎn)生出來。注意上述步驟 3 和 4 的順序在 JVM 規(guī)范中并未嚴(yán)格限定不同虛擬機(jī)的實(shí)現(xiàn)可能不同。對象創(chuàng)建后其生命周期就與垃圾回收機(jī)制緊密相關(guān)。對象頭中的 Mark Word 部分就包含了用于垃圾回收的標(biāo)記信息如分代年齡、鎖狀態(tài)標(biāo)志等。2. 深入理解 Java 內(nèi)存模型與 volatile 關(guān)鍵字并發(fā)編程是 Java 高級面試的必考領(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)存副本。線程對變量的所有操作都必須在工作內(nèi)存中進(jìn)行而不能直接讀寫主內(nèi)存中的變量。不同線程之間也無法直接訪問對方工作內(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ù)。它包括程序次序規(guī)則、管程鎖定規(guī)則、volatile 變量規(guī)則、線程啟動(dòng)規(guī)則、線程終止規(guī)則、線程中斷規(guī)則、對象終結(jié)規(guī)則和傳遞性。2.3 volatile 如何保證可見性與禁止指令重排序volatile是輕量級的同步機(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使用場景是雙重檢查鎖定實(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) 初始化對象。如果線程 A 執(zhí)行到步驟 2 后線程 B 進(jìn)入第一個(gè)if (instance null)判斷會(huì)發(fā)現(xiàn) instance 不為 null從而直接返回一個(gè)尚未初始化完成的對象導(dǎo)致錯(cuò)誤。volatile可以禁止這種重排序保證對象的初始化在引用賦值之后完成。注意volatile不保證原子性。i這種復(fù)合操作讀-改-寫即使在volatile修飾下也不是線程安全的。3. synchronized 與 ReentrantLock 的深度對比兩者都是可重入鎖但設(shè)計(jì)哲學(xué)和實(shí)現(xiàn)機(jī)制有顯著不同。3.1 實(shí)現(xiàn)機(jī)制與性能演變synchronizedJVM 層面的關(guān)鍵字通過monitorenter和monitorexit字節(jié)碼指令實(shí)現(xiàn)。鎖信息存儲(chǔ)在對象頭的 Mark Word 中。在 JDK 1.6 之前它是重量級鎖性能較差。JDK 1.6 之后進(jìn)行了大規(guī)模優(yōu)化引入了偏向鎖、輕量級鎖、重量級鎖的鎖升級機(jī)制以及鎖消除、鎖粗化等優(yōu)化手段使得其性能在大多數(shù)場景下與ReentrantLock相差無幾甚至更優(yōu)因?yàn)橛?JVM 自動(dòng)優(yōu)化。ReentrantLockJDK 層面實(shí)現(xiàn)的類基于AbstractQueuedSynchronizer隊(duì)列同步器。它提供了比synchronized更豐富的功能。3.2 功能特性對比特性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()與對象監(jiān)視器配合可綁定多個(gè)Condition對象實(shí)現(xiàn)更精細(xì)的線程等待/喚醒嘗試獲取鎖不支持支持tryLock()可設(shè)置超時(shí)時(shí)間3.3 選型建議與常見誤區(qū)如何選擇優(yōu)先使用 synchronized除非你需要ReentrantLock獨(dú)有的高級功能如可中斷、超時(shí)、公平鎖、多個(gè)條件變量否則應(yīng)優(yōu)先使用synchronized。理由是其簡潔、自動(dòng)釋放、由 JVM 持續(xù)優(yōu)化且不易出錯(cuò)忘記解鎖是ReentrantLock的常見錯(cuò)誤。需要高級功能時(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)化下兩者在低競爭場景下性能接近。高競爭場景下synchronized升級為重量級鎖后性能與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)鏈表長度超過閾值默認(rèn)為 8且數(shù)組長度大于等于 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ù)組的長度必須是 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 流程簡述計(jì)算 key 的 hash。如果 table 為空則初始化。如果定位到的桶為空使用 CAS 嘗試寫入失敗則自旋保證成功。如果桶不為空hash MOVED說明正在擴(kuò)容則幫助擴(kuò)容。如果桶不為空則使用synchronized鎖住桶的頭節(jié)點(diǎn)鏈表或樹進(jìn)行插入或更新操作。如果鏈表長度超過閾值則轉(zhuǎn)換為紅黑樹。最后檢查容量決定是否擴(kuò)容。5. Spring 框架中 Bean 的生命周期理解 Bean 的生命周期是掌握 Spring 框架核心機(jī)制的關(guān)鍵它串聯(lián)了 IOC 容器、AOP、事務(wù)管理等諸多功能。5.1 一個(gè) Bean 從誕生到銷毀的完整旅程對于普通的 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í)行對應(yīng)的初始化方法。自定義 init-method如果在 Bean 定義中指定了init-method則執(zhí)行該方法。BeanPostProcessor.postProcessAfterInitialization所有BeanPostProcessor的postProcessAfterInitialization方法被調(diào)用。AOP 代理對象的生成通常發(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í)行對應(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è)代理對象并返回這個(gè)代理對象替代原始 Bean。這就是為什么我們Autowired注入的實(shí)際上是一個(gè)代理對象。5.3 循環(huán)依賴的解決原理Spring 默認(rèn)支持單例模式下的屬性注入Setter/Field循環(huán)依賴但不支持構(gòu)造器注入的循環(huán)依賴。其解決原理依賴于三級緩存一級緩存 singletonObjects存放完全初始化好的 Bean。二級緩存 earlySingletonObjects存放提前暴露的、尚未完成屬性注入和初始化的 Bean早期引用。三級緩存 singletonFactories存放 Bean 工廠對象用于生成早期引用。解決流程以 A 依賴 BB 依賴 A 為例創(chuàng)建 A實(shí)例化后將 A 的工廠對象放入三級緩存。為 A 注入屬性 B發(fā)現(xiàn) B 不存在開始創(chuàng)建 B。創(chuàng)建 B實(shí)例化后將 B 的工廠對象放入三級緩存。為 B 注入屬性 A從一級緩存未找到 A但從三級緩存找到了 A 的工廠對象。工廠對象生成 A 的早期引用可能是原始對象也可能是代理對象并將其放入二級緩存同時(shí)從三級緩存移除。B 成功獲得 A 的早期引用完成屬性注入和初始化成為一個(gè)完整的 Bean放入一級緩存并清理二、三級緩存?；氐?A 的創(chuàng)建流程此時(shí)可以從一級緩存直接拿到完整的 B完成 A 的屬性注入和初始化。A 完成后也放入一級緩存。注意原型Prototype作用域的 Bean 不支持循環(huán)依賴因?yàn)?Spring 不緩存原型 Bean。6. 數(shù)據(jù)庫事務(wù)隔離級別與 Spring 事務(wù)傳播行為這是連接數(shù)據(jù)庫理論與 Spring 實(shí)踐的核心問題。6.1 數(shù)據(jù)庫事務(wù)的四大特性與隔離級別ACID原子性事務(wù)是一個(gè)不可分割的工作單位。一致性事務(wù)執(zhí)行前后數(shù)據(jù)庫從一個(gè)一致性狀態(tài)變換到另一個(gè)一致性狀態(tài)。隔離性多個(gè)并發(fā)事務(wù)之間互不干擾。持久性事務(wù)一旦提交對數(shù)據(jù)的改變是永久性的。隔離級別為了解決并發(fā)問題讀未提交一個(gè)事務(wù)可以讀到另一個(gè)事務(wù)未提交的數(shù)據(jù)。存在臟讀、不可重復(fù)讀、幻讀問題。讀已提交一個(gè)事務(wù)只能讀到另一個(gè)事務(wù)已提交的數(shù)據(jù)。解決了臟讀但存在不可重復(fù)讀、幻讀問題。這是 Oracle 的默認(rèn)級別?？芍貜?fù)讀一個(gè)事務(wù)執(zhí)行過程中看到的數(shù)據(jù)總是跟這個(gè)事務(wù)啟動(dòng)時(shí)看到的數(shù)據(jù)是一致的。解決了臟讀和不可重復(fù)讀但存在幻讀問題。這是 MySQL InnoDB 的默認(rèn)級別通過 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ù)。常見使用場景REQUIRED最常用適用于大多數(shù)業(yè)務(wù)方法。REQUIRES_NEW用于日志記錄、消息發(fā)送等獨(dú)立操作即使主業(yè)務(wù)失敗這些操作也需要提交。NESTED用于可獨(dú)立回滾的子業(yè)務(wù)例如一個(gè)訂單處理流程中扣減庫存和生成物流單可以放在嵌套事務(wù)中如果生成物流單失敗可以只回滾這部分而不影響庫存扣減。6.3 Transactional 失效的常見場景方法非 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指針而不是代理對象。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后臺異步命令。自動(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í)對性能的影響比 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è)請求都能收到一個(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)必須面對的現(xiàn)實(shí)因此 P 是必須保障的。于是實(shí)際的選擇就變成了CP 還是 AP。CP 系統(tǒng)當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)時(shí)為了保證一致性系統(tǒ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 理論對 CAP 中一致性和可用性權(quán)衡的結(jié)果BASE 理論是對 CAP 中一致性和可用性權(quán)衡的一種實(shí)踐方案其核心思想是即使無法做到強(qiáng)一致性但系統(tǒng)可以采用適當(dāng)?shù)姆绞竭_(dá)到最終一致性?；究捎孟到y(tǒng)在出現(xiàn)不可預(yù)知故障時(shí)允許損失部分可用性如響應(yīng)時(shí)間變長、功能降級。軟狀態(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)一致性相對?；ヂ?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ù)注冊中心高可用是關(guān)鍵。節(jié)點(diǎn)間通過異步復(fù)制同步數(shù)據(jù)允許在短時(shí)間內(nèi)各節(jié)點(diǎn)數(shù)據(jù)不一致但能保證服務(wù)注冊與發(fā)現(xiàn)的基本可用。Redis Cluster (AP)默認(rèn)情況下當(dāng)主節(jié)點(diǎn)故障且無法完成故障轉(zhuǎn)移時(shí)集群仍然可以處理請求可能讀到舊數(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ù)庫唯一約束如訂單號。在 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)功能將長 URL 轉(zhuǎn)換為短 URL訪問短 URL 時(shí)重定向到原始長 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)是簡單、無碰撞缺點(diǎn)是短碼長度不固定且可能被推測出業(yè)務(wù)量。Hash 算法對長 URL 進(jìn)行 MD5 或 MurmurHash 計(jì)算取哈希值的前若干位作為短碼。優(yōu)點(diǎn)是長度固定缺點(diǎn)是存在哈希沖突需要解決。解決沖突如果發(fā)生沖突可以在原 URL 后附加一個(gè)隨機(jī)鹽值重新計(jì)算哈?；蛘呤褂貌悸∵^濾器預(yù)先判斷。推薦方案對于一般系統(tǒng)使用Snowflake 生成 ID 62 進(jìn)制轉(zhuǎn)換是平衡復(fù)雜度和性能的好選擇。對于要求短碼長度固定且不可預(yù)測的場景可以考慮使用Hash 算法 沖突檢測與重試。10.3 系統(tǒng)架構(gòu)與組件設(shè)計(jì)服務(wù)層生成服務(wù)接收長 URL通過算法生成短碼將映射關(guān)系持久化返回短 URL。重定向服務(wù)接收短碼查詢對應(yī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è)置較長 TTL。關(guān)鍵流程生成流程用戶提交長 URL?？蛇x先查緩存或庫看是否已存在該長 URL 的短碼防重復(fù)。調(diào)用 ID 生成器獲取唯一 ID。將 ID 轉(zhuǎn)換為 62 進(jìn)制短碼。將(短碼, 長 URL)寫入數(shù)據(jù)庫和緩存。返回短 URL如http://short.com/abc123。重定向流程用戶訪問短 URL。Nginx 等網(wǎng)關(guān)層解析出短碼。首先查詢 Redis 緩存。若緩存未命中查詢數(shù)據(jù)庫。若數(shù)據(jù)庫命中將長 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 高級面試考察的是對技術(shù)原理的透徹理解、對生產(chǎn)實(shí)踐的經(jīng)驗(yàn)積累以及解決復(fù)雜問題的系統(tǒng)化思維。掌握這些知識不僅是為了通過面試更是為了在實(shí)際工作中能夠設(shè)計(jì)出更穩(wěn)健的系統(tǒng)更高效地排查和解決問題。建議在理解上述原理的基礎(chǔ)上結(jié)合源碼閱讀和實(shí)際項(xiàng)目經(jīng)驗(yàn)形成自己的知識體系和判斷力。