帶人面試這幾年Java異常幾乎是必問題而且問法一年比一年刁鉆。從最基礎(chǔ)的Throwable下面分哪兩類到finally里 return 會不會覆蓋 try 里的返回值再到為什么不要在 finally 里拋異常每一層都能篩掉一批人。坦白說異常處理在大多數(shù)人日常代碼里就是無腦 try-catch 的肌肉記憶但面試官想看的恰恰是你在異常機制上有沒有真正的底層理解。這篇就按我實際帶新人、做面試官時的經(jīng)驗把 Java 異常面試?yán)镒畛１粏柕降?0道經(jīng)典面試題拆開來講每一道都會說清楚考什么、坑在哪、怎么答才夠深。1. 先搞清楚Java異常體系這5道題別再送分了1.1 體系結(jié)構(gòu)Throwable、Exception、Error三者到底什么關(guān)系Java 里所有的異常和錯誤歸根到底都是 Throwable 的子類。Throwable 這一層下面分兩個大分支Exception 和 Error。Exception 里面又細(xì)分成 RuntimeException非受檢異常和除了 RuntimeException 之外的其他受檢異常。很多剛工作沒兩年的人能說出這個結(jié)論但一問到設(shè)計意圖就卡殼。Throwable 這個類名字本身就很直白可以被拋出它定義了所有異常對象的公共能力message描述信息、cause導(dǎo)致當(dāng)前異常的根本原因、stackTrace異常堆?？煺铡２还苁强罩羔樳€是數(shù)據(jù)庫連接失敗最后都?xì)w一成同一個模型這保證了 JVM 在處理異常時能用統(tǒng)一邏輯。面試官問體系結(jié)構(gòu)通常背后還有一層意思你平時看代碼時有沒有關(guān)注過異常的類型歸屬。比如很多面試者會把 RuntimeException 和 Error 混為一談其實兩者在異常處理哲學(xué)上完全不同。RuntimeException 代表程序邏輯缺陷比如空指針、下標(biāo)越界理論上可以通過修復(fù)代碼避免Error 代表 JVM 或系統(tǒng)級的嚴(yán)重問題比如 OutOfMemoryError程序自己通常無法修復(fù)。你可以在代碼里 catch OOM但基本治標(biāo)不治本因為內(nèi)存已經(jīng)處于危險狀態(tài)。順帶提一個比較冷門但面試官很喜歡的點Throwable 不僅僅能用來封裝 Exception 和 Error你甚至可以把自定義的 Throwable 子類當(dāng)作業(yè)務(wù)異常使用只要調(diào)用方愿意。但實際工程里幾乎沒人這么干約定俗成是繼承 Exception 或 RuntimeException。如果你在回答體系結(jié)構(gòu)時能補充說異常不只是一種錯誤報告機制也是一種控制流裁定的手段整個回答的深度立刻不一樣。1.2 Checked與Unchecked面試官最愛的二分法受檢異常Checked Exception和非受檢異常Unchecked Exception的區(qū)別是 Java 異常面試的必考題。受檢異常必須顯式處理要么用 try-catch 包裹要么在方法簽名里用 throws 聲明非受檢異常則沒有這個限制編譯器不會強制你去處理。為什么 Java 要專門設(shè)計這種強制性的區(qū)分我的理解是受檢異常表達的是調(diào)用方需要為這種可預(yù)期的失敗負(fù)責(zé)的場景。比如你打開一個文件文件不存在是常見業(yè)務(wù)風(fēng)險編譯器有義務(wù)提醒你處理。而 RuntimeException 表達的更多是程序內(nèi)部邏輯有問題或狀態(tài)根本不可用出了錯不是調(diào)用方靠 try-catch 就能兜底的得靠修代碼。面試時如果只答到這里只能拿及格分更高一檔的回答要說到工程實踐的變化趨勢。我?guī)У捻椖坷镄碌臉I(yè)務(wù)代碼幾乎不再主動聲明受檢異常了而是統(tǒng)一拋 RuntimeException 的子類靠全局異常處理器統(tǒng)一捕獲。原因很簡單受檢異常把處理異常的壓力傳遞給了每一個調(diào)用方在多層調(diào)用鏈上導(dǎo)致大量被迫的 try-catch 或者 throws 污染代碼可讀性直線下降。但要注意這不代表受檢異常沒有存在價值像讀寫文件、網(wǎng)絡(luò)通訊這類底層 IO 場景強制處理依然有它的合理性。我用一個表格幫人記憶兩類異常的核心差異面試前過一遍很有用。對比維度Checked ExceptionUnchecked Exception父類位置Exception 下除 RuntimeException 之外RuntimeException 子類編譯期強制處理必須 try-catch 或 throws不強制典型場景IO、網(wǎng)絡(luò)、配置加載空指針、非法參數(shù)、下標(biāo)越界設(shè)計意圖可預(yù)期的業(yè)務(wù)/環(huán)境風(fēng)險程序邏輯缺陷或不可恢復(fù)狀態(tài)工程建議底層 IO 或強約束時使用業(yè)務(wù)系統(tǒng)推薦使用1.3 Error能catch嗎能但踩過的坑比想象多很多人一聽到 Error 就先入為主認(rèn)為不能 catch這其實是錯的。從語法層面catch (Error e) 完全合法JVM 也不會阻止你。但從工程角度我強烈不建議你去接 Error原因不是接不住而是接了也處理不了。拿 OutOfMemoryError 來說當(dāng)它出現(xiàn)時堆內(nèi)存可能已經(jīng)耗盡你即使 catch 住想通過清理緩存釋放內(nèi)存大概率也來不及甚至 catch 之后 JVM 再觸發(fā) GC 也沒有足夠空間。StackOverflowError 更典型無限遞歸導(dǎo)致棧溢出之后線程的調(diào)用棧已經(jīng)極深你再做什么都很難讓程序恢復(fù)到安全狀態(tài)。有一個實際教訓(xùn)可以分享某個后臺任務(wù)為了避免崩潰在頂層用了 catch (Throwable e) 做兜底結(jié)果某次 OOM 被吞掉之后系統(tǒng)對外看起來還活著但內(nèi)部內(nèi)存已經(jīng)瀕臨崩潰后續(xù)每一個請求都在失敗邊緣掙扎排查了很久才定位到是 OOM 被吞導(dǎo)致的可悲狀態(tài)。所以我的建議是除非是熱備切換、資源清理這類極端兜底場景否則頂層也別輕易 catch Throwable寧可讓進程快速失敗也不要帶病運行。1.4 常見運行時異常背全清單就是送分運行時異常RuntimeException是面試題里最常被拿來舉例的一類。下面這些是高頻出現(xiàn)的我按觸發(fā)場景整理了一下NullPointerException空引用訪問成員變量、方法或數(shù)組元素時觸發(fā)。最經(jīng)典也最常見。IndexOutOfBoundsException訪問數(shù)組或集合時下標(biāo)越界注意區(qū)分 ArrayIndexOutOfBoundsException 和 StringIndexOutOfBoundsException。ClassCastException強制類型轉(zhuǎn)換失敗比如把 Object 轉(zhuǎn)成不兼容的類型。ArithmeticException算術(shù)異常最常見的就是整數(shù)除零。IllegalArgumentException方法接收到了非法的參數(shù)比如數(shù)值范圍不合法。IllegalStateException對象狀態(tài)不滿足操作前提比如已經(jīng)關(guān)閉的連接再調(diào)用方法。NumberFormatException字符串轉(zhuǎn)數(shù)字失敗。UnsupportedOperationException調(diào)用了未實現(xiàn)的操作一般出現(xiàn)在只讀集合上。記這個清單不能只背名字面試官往往會給出一個小場景讓你判斷會拋什么異常。比如HashMap 的 key 是自定義對象對象沒有重寫 hashCode 會怎樣答案是可能正常工作但 hashCode 相等的對象會被放到同一個槽位性能變差。想靠背清單應(yīng)付不了這種場景題平時寫代碼遇到異常時多看一眼類型和堆棧比死記硬背更有用。1.5 throw與throws一拋一聲明的區(qū)別常常被問倒throw 和 throws 看起來只差一個字母但語義完全不同。throw 用在方法體內(nèi)部表示實際拋出一個異常實例后面必須跟一個 Throwable 對象throws 用在方法簽名上表示這個方法可能拋出哪些異常類型是把異常責(zé)任向上傳遞的聲明。舉個簡單的對比public class ThrowVsThrows { public static void main(String[] args) { try { doSomething(); } catch (BusinessException e) { System.out.println(捕獲到了業(yè)務(wù)異常); } } // 用 throws 聲明可能拋出的受檢異常 public static void doSomething() throws BusinessException { // 滿足條件時實際拋出異常實例 throw new BusinessException(參數(shù)不合法); } }這里可以看出一個設(shè)計邏輯throws 解決的是夠不到異常的問題——當(dāng)前方法把異常拋給上層由上層決定怎么處理。而 throw 解決的是這里確實發(fā)生了異常情況的問題。面試時如果被問到能不能只 throw 不 throws答案是可以只要拋的是 RuntimeException 或它的子類。反過來能不能只 throws 不 throw也行因為 throws 只是一種聲明不代表方法內(nèi)一定要拋。很多面試者死記硬背throw 是動作、throws 是聲明這沒錯但我會希望聽到你把異常責(zé)任傳遞鏈這個概念講出來throws 本質(zhì)是在協(xié)議層面告訴調(diào)用方調(diào)用這里需要做什么心理準(zhǔn)備。2. try-catch-finally執(zhí)行機制最容易踩坑的5道題2.1 執(zhí)行順序finally一定執(zhí)行嗎別急著回答是這個問題的經(jīng)典程度不用多說。標(biāo)準(zhǔn)流程是try 塊正常執(zhí)行完畢接著執(zhí)行 finallytry 塊拋異常先匹配 catchcatch 執(zhí)行完再 finally沒有匹配的 catchfinally 執(zhí)行完后異常繼續(xù)向上拋。很多人只知道finally 最后執(zhí)行但被問到finally 一定執(zhí)行嗎就開始猶豫了。實際情況是只要 JVM 沒有被強制終止finally 都會執(zhí)行。觸發(fā)強制終止的典型情況包括 System.exit() 調(diào)用、JVM 崩潰、機器斷電。此外如果 try 塊所在線程被中斷或 killfinally 的執(zhí)行也不可靠。還有一個容易忽略的點如果 try 塊里出現(xiàn)無限循環(huán)finally 自然永遠執(zhí)行不到——這不是它不執(zhí)行而是沒有執(zhí)行的機會。這里的原理是 finally 的設(shè)計目標(biāo)保證資源釋放、狀態(tài)清理等收尾工作不因 try 塊正常或異常而改變。所以寫 finally 時要假設(shè)它一定會執(zhí)行不要在里面寫可能失敗的操作也不要寫耗時操作保持 finally 足夠輕量。面試時對方還可能追問finally 里能不能修改返回值這句要小心。修改的行為要區(qū)分基本類型和引用類型?；绢愋驮?finally 里改返回值變量不會影響已經(jīng)計算好的返回值引用類型則要看修改的是變量指向還是對象內(nèi)部狀態(tài)。對象內(nèi)部狀態(tài)變了外部拿到的引用自然感知到變化。這個點放到下一題細(xì)化。2.2 return和finally到底誰先誰后return 和 finally 的執(zhí)行順序光靠return 先計算值finally 后執(zhí)行最后返回這句話不夠得結(jié)合字節(jié)碼層面理解。我在實操中發(fā)現(xiàn)很多人聽到finally 在 return 之前執(zhí)行后反而誤解成finally 先執(zhí)行、return 語句后執(zhí)行這是錯的。準(zhǔn)確說法是return 表達式求值發(fā)生在 finally 執(zhí)行之前但方法真正把值返回給調(diào)用方發(fā)生在 finally 執(zhí)行完成后?？磦€例子public class ReturnFinallyOrder { public static void main(String[] args) { System.out.println(compute()); } static int compute() { int result 1; try { result 2; return result; // 先把返回值 2 存到臨時位置 } finally { result 3; // 修改 result不影響已暫存的返回值 System.out.println(finally 執(zhí)行result result); } } }這里輸出會是finally 先打印 finally 執(zhí)行result3然后方法返回 2。很多人以為返回 3實際是 2。原因就是 return 的求值動作在 finally 之前完成返回值已經(jīng)被復(fù)制到臨時槽位后續(xù)對局部變量的修改不影響它。但如果 return 的是一個引用類型比如 HashMapfinally 里往這個 map 里 put 數(shù)據(jù)調(diào)用方拿到的是同一對象會看到 put 后的內(nèi)容。這個細(xì)節(jié)在面試?yán)锖苡袇^(qū)分度能體現(xiàn)你對值傳遞和引用傳遞的理解。2.3 finally里寫return一個能幫你加分也能踩坑的操作finally 里寫 return 是絕對要被 interviewer 重點盤問的因為它會覆蓋 try 或 catch 里的返回值。舉例public static int overrideDemo() { try { throw new RuntimeException(業(yè)務(wù)出錯); } catch (RuntimeException e) { return 100; } finally { return 200; } }這段代碼運行時不會把異常傳出去最終返回值是 200。也就是 catch 里 return 100 已經(jīng)執(zhí)行了但 finally 里的 return 200 把返回路徑搶過去覆蓋掉了。更嚴(yán)重的是try 拋出的異常也被吞掉了調(diào)用方完全不知道業(yè)務(wù)出錯。這種代碼在很多老項目里見過通常是為了在異常情況下給一個默認(rèn)返回值看似穩(wěn)妥實則后患無窮。一旦異常被吞掉線上故障排查時日志里什么都看不到問題定位成本劇增。我的建議是 finally 里只做清理和狀態(tài)復(fù)位永遠不要寫 return也不要寫會拋異常的業(yè)務(wù)邏輯。這不是理論潔癖是真金白銀踩坑換來的教訓(xùn)。2.4 try-with-resources編譯器幫你把close的正確姿勢寫好try-with-resources 是 Java 7 引入的語法糖它的核心價值不只是簡潔而是解決了傳統(tǒng) finally close 的異常掩蓋問題。先看傳統(tǒng)寫法的問題// 不推薦的傳統(tǒng)寫法 InputStream in null; try { in new FileInputStream(test.txt); // 讀文件 } finally { if (in ! null) { in.close(); // 如果close拋異常會覆蓋try塊里的原始異常 } }如果 try 塊里讀文件時拋了 IOExceptionfinally 里 close 又拋了 IOException傳統(tǒng)寫法下小概率會把 close 的異常覆蓋掉原始異常導(dǎo)致你看到的異常根本不是根因。而 try-with-resources 會自動處理抑制異常底層 IOException 和 close 的 IOException 都會記錄close 的異常會被標(biāo)記為 suppressed可以通過 Throwable.getSuppressed() 查出來。語法很簡單try (FileInputStream in new FileInputStream(test.txt); BufferedInputStream bin new BufferedInputStream(in)) { // 使用資源 } catch (IOException e) { // 處理 }兩個實現(xiàn)細(xì)節(jié)值得記住第一資源聲明要放在 try 后的括號里并且資源必須實現(xiàn) AutoCloseable第二多個資源的關(guān)閉順序與聲明順序相反類似棧的后進先出。比如先聲明 in 再聲明 bin關(guān)閉時先關(guān) bin再關(guān) in。這個順序的目的是保證依賴方向正確避免外層資源關(guān)閉后內(nèi)層資源還被引用。2.5 多重catch的匹配順序子類在前父類在后多個 catch 塊并存時異常匹配是從上到下的順序。Java 不會為你選最合適的 catch它只按書寫順序找第一個能接住這個異常類型的塊。所以如果父類 Exception 寫在子類 IOException 前面IOException 的 catch 塊永遠到不了編譯器會直接報錯該異常已經(jīng)被父類 catch 捕獲。Java 7 引入的多異常捕獲語法也常被追問try { // 讀寫文件、解析格式 } catch (IOException | ParseException e) { // 統(tǒng)一處理e日志輸出 }注意這里 catch 參數(shù) e 的隱式類型是這些異常的公共父類而且 e 被隱式聲明為 final不能在 catch 塊里重新賦值。這個細(xì)節(jié)很多人答不上來。為什么要多個 catch一個復(fù)雜方法可能面臨網(wǎng)絡(luò)異常、解析異常、業(yè)務(wù)校驗異常同時存在拆分 catch 塊能讓你針對不同情況進行差異化處理而用多異常捕獲則是讓處理邏輯相同時避免重復(fù)代碼。3. 異常設(shè)計原則從懂語法到會設(shè)計的5道題3.1 什么時候該捕獲什么時候該拋出一條判據(jù)走天下我面試時經(jīng)常給出一道場景題你在 service 層調(diào)用 dao 層dao 層拋了個 SQLException你該怎么辦很多候選人第一反應(yīng)是 try-catch 包起來然后打印日志這恰恰是最需要糾正的習(xí)慣。判斷該捕獲還是該拋出的關(guān)鍵是看當(dāng)前層能不能對異常做出有意義的補償。如果當(dāng)前層有降級方案、可以重試、能返回兜底數(shù)據(jù)那就捕獲如果當(dāng)前層什么都做不了就應(yīng)該向上拋把選擇權(quán)交給更上層。service 層面對 SQLException 時常見的正確處理是轉(zhuǎn)化為自己的業(yè)務(wù)異常再拋出去或者回滾事務(wù)后拋給 controller而不是默默吞掉然后返回 null 告訴上面我沒出錯?？梢詮姆謱右暯遣痖_說DAO 層一般不適合直接處理異常向上拋或轉(zhuǎn)成數(shù)據(jù)訪問異常讓 service 層決定是否重試或回滾。Service 層可以處理與業(yè)務(wù)狀態(tài)相關(guān)的異常做補償、重試、回滾等。Controller/API 層捕獲通用異常轉(zhuǎn)換成統(tǒng)一的響應(yīng)結(jié)構(gòu)返回給客戶端。答案里如果能強調(diào)異常處理的原則不是消除異常而是把異常放在最合適的一層去應(yīng)對面試官會覺得你有工程判斷力。3.2 自定義異常命名、繼承、構(gòu)造函數(shù)、錯誤碼自定義異常是設(shè)計題的重災(zāi)區(qū)。很多人知道要繼承 RuntimeException但構(gòu)造函數(shù)不完整導(dǎo)致后續(xù)排錯缺信息。一個合格的自定義異常至少要考慮四件事。第一繼承誰。業(yè)務(wù)系統(tǒng)中我強烈建議繼承 RuntimeException因為受檢異常會污染調(diào)用鏈但如果你的異常需要強制調(diào)用方感知處理比如參數(shù)校驗異?？梢岳^承 Exception。第二命名規(guī)范。以 Exception 結(jié)尾比如 OrderException、PayException千萬不要叫 OrderError 之類。第三構(gòu)造函數(shù)完整。最好覆蓋無參、帶 message、帶 message 和 cause 三個構(gòu)造。有時還要提供帶 errorCode 的版本。第四是否攜帶更多上下文。業(yè)務(wù)異常最好帶 errorCode方便前端展示對應(yīng)文案和產(chǎn)品側(cè)定位。下面是一個我常用的模板public class OrderException extends RuntimeException { private final int errorCode; public OrderException(int errorCode, String message) { super(message); this.errorCode errorCode; } public OrderException(int errorCode, String message, Throwable cause) { super(message, cause); this.errorCode errorCode; } public int getErrorCode() { return errorCode; } }這樣做的好處是全局異常處理器捕獲到 OrderException 后可以直接取出 errorCode 返回給前端不需要再通過字符串解析業(yè)務(wù)錯誤。平時寫業(yè)務(wù)代碼時自定義異常別亂造一個模塊里有三五個穩(wěn)定的異常類型就夠了不要每個方法都 new 一個異常類。3.3 異常日志把堆棧和上下文一起打出來才叫有效異常日志是我在實際項目中復(fù)查最多的點。很多線上問題排查困難不是因為難而是日志里只有 e.getMessage()連堆棧都沒有。你說一個 NullPointerException 出現(xiàn)在哪一行都不知道排查只能靠猜。正確做法是把整個異常對象傳給日志框架而不是只傳 message。用日志框架的寫法是// 不推薦只打印message丟失堆棧 log.error(處理失敗 e.getMessage()); // 推薦傳入異常對象自動記錄堆棧 log.error(訂單{}處理失敗訂單狀態(tài){}, orderId, status, e);第二個寫法的好處有兩個一是堆棧完整能定位到具體拋出點二是上下文參數(shù)能幫你理解這個異常發(fā)生在什么業(yè)務(wù)背景下。日志里最忌諱的就是只有報錯文案沒有訂單號、沒有用戶標(biāo)識、沒有調(diào)用來源這種日志在排查時基本報廢。還有一個重復(fù)記錄的問題。很多團隊在 DAO 層記一次service 層又記一次controller 層再記一次一個異常出現(xiàn)三份日志看起來信息很全實際上分散了排查注意力而且不同層記錄時間可能有細(xì)微差異反而干擾判斷。我的做法是在最終處理異常的那一層記一次完整日志中間層做異常包裝時可以簡記或不記保持日志鏈路干凈。3.4 避免空指針從防御式寫法到Optional的正確姿勢NullPointerException 一出現(xiàn)Java 面試的氣氛瞬間就活了。面試官想看的不是你背了多少判空方法而是你有沒有形成系統(tǒng)的空值防護意識。日常代碼里最常用的防護手段是提前判斷比如方法入口校驗參數(shù)public void process(Order order) { if (order null) { throw new IllegalArgumentException(order不能為空); } if (order.getId() null) { throw new IllegalArgumentException(order.id不能為空); } // 業(yè)務(wù)處理 }Java 8 之后 Optional 也很流行但用錯的人很多。Optional 適合用作返回值表達可能沒有值它不適合用來做字段類型也不適合作為方法參數(shù)傳進來——把 Optional 傳進方法意味著你又得判斷一次外層 Optional 是否為空反而復(fù)雜化了。有一個比較新的點也可以提JDK 14 之后 JVM 對空指針有更友好的診斷信息出現(xiàn) NPE 時能直接提示是哪個字段為 null而不是籠統(tǒng)地拋一個堆棧。面試時提到Helpful NullPointerException能顯得你持續(xù)在跟進版本演進很加分。另外Objects.requireNonNull 是一個被低估的利器它可以在方法入?yún)⑿ｒ灂r快速拋出 NPE比手寫 if throw 簡潔而且語義清晰。3.5 濫用異常做業(yè)務(wù)分支為什么會成為面試反面教材有一類代碼很能暴露程序員水平就是拿異常當(dāng)正常的業(yè)務(wù)判斷用。典型情況是把整個方法用 try-catch 包住通過 catch 某個特定異常來推出循環(huán)或者設(shè)置默認(rèn)值。這樣做的大問題有三個。第一是性能。異常創(chuàng)建需要填充堆棧這是一次棧幀遍歷成本遠高于普通 if 判斷如果循環(huán)每輪都走異常分支性能影響可能非常顯著。第二是可讀性。異常名本質(zhì)上代表非常規(guī)狀態(tài)它混入正常流程會讓閱讀者無法判斷哪些情況是預(yù)期哪些是真錯誤。第三是安全。一旦 catch 塊寫得不嚴(yán)謹(jǐn)真正的錯誤可能被當(dāng)作正常業(yè)務(wù)吞掉。正確的業(yè)務(wù)分支做法是預(yù)期內(nèi)的狀態(tài)用 if 判斷或 switch 分支預(yù)期外的錯誤用異常表達。比如根據(jù)訂單狀態(tài)決定下一步是分支邏輯應(yīng)該用枚舉加 switch外部接口響應(yīng)異常才是異常邏輯應(yīng)該拋出去或按降級策略處理。舉一個反例// 反例把數(shù)組邊界當(dāng)成循環(huán)結(jié)束信號 try { while (true) { System.out.println(list.get(i)); } } catch (IndexOutOfBoundsException e) { // 用異常結(jié)束循環(huán) }這種寫法如果在面試題里出現(xiàn)基本就是考察你對異常只用于非常規(guī)狀態(tài)的理解。能一眼看出問題并且解釋清原因的人才算是真正理解異常設(shè)計的本質(zhì)。4. 異常高級場景拉開面試差距的5道題4.1 異常的性能代價別用異?？刂屏鞒谈丛诙褩Ｌ畛溥@道題往往藏在一個更寬泛的問題里為什么說不要用異常處理正常流程性能是最核心的技術(shù)原因。異常對象創(chuàng)建時JVM 會調(diào)用 fillInStackTrace()這個方法會遍歷當(dāng)前線程的調(diào)用棧把每一層棧幀記錄下來。調(diào)用棧越深遍歷成本越高而且這個過程是 JVM 原生的異常拋出頻率一旦高起來對系統(tǒng)吞吐的影響非常明顯。我用一個簡單測試驗證過普通的 for 循環(huán)加 if 判斷和同樣循環(huán)里故意拋異常再捕獲吞吐差距能到幾十倍以上異常方式甚至可能把機器打滿。這個數(shù)據(jù)背后的原理就是 fillInStackTrace 的棧遍歷和對象分配開銷。不過在特定場景下如果你確實需要一個異常對象但又完全不需要堆棧信息比如某些自定義的輕量級業(yè)務(wù)狀態(tài)信號可以覆蓋 fillInStackTrace 讓異常創(chuàng)建成本大幅下降public class LightweightStatusException extends RuntimeException { Override public synchronized Throwable fillInStackTrace() { return this; // 不填充堆棧加快異常創(chuàng)建 } }這個技巧面試時能講出來會非常亮眼。但它也帶來一個代價異常對象沒有堆棧排錯完全靠 message 和上下文日志除非你對場景非常有把握否則不建議在生產(chǎn)大量使用。4.2 線程里的異常run方法簽名上沒有throws怎么辦Runnable 的 run() 方法沒有聲明 throws所以受檢異常根本拋不出去只能在 run 內(nèi)部 try-catch。很多人在這里的認(rèn)知是線程出異常會直接掛掉對但不夠準(zhǔn)確。如果線程沒有被自定義的 UncaughtExceptionHandler 接管默認(rèn)處理邏輯是把異常堆棧打印到 System.err然后線程結(jié)束。對于線程池里的工作線程來說是線程結(jié)束而不是整個線程池掛掉。面試常給的一道進階題是把任務(wù)提交給 ThreadPoolExecutor任務(wù)內(nèi)部拋出 RuntimeException調(diào)用方怎么感知這要區(qū)分提交方式。如果用 execute() 提交異常默認(rèn)會被線程池內(nèi)部吞掉外部拿不到如果用 submit() 返回 Future異常會被封裝成 ExecutionException在調(diào)用 future.get() 時拋出。ExecutorService pool Executors.newFixedThreadPool(2); Future? future pool.submit(() - { throw new RuntimeException(任務(wù)內(nèi)部失敗); }); try { future.get(); } catch (ExecutionException e) { Throwable cause e.getCause(); // 真正的任務(wù)異常 System.out.println(捕獲任務(wù)異常 cause.getMessage()); } catch (InterruptedException e) { Thread.currentThread().interrupt(); }這個寫法里通過 ExecutionException 拿到 cause 才能看到真正異常直接捕獲到的是包裝后的異常。能講清楚 execute、submit、Future.get 這三種異常感知路徑的人說明對線程池有實操經(jīng)驗不是只看過文檔。4.3 異常丟失為什么日志里明明該有異常卻什么都沒有異常丟失是生產(chǎn)事故里最隱蔽的坑。最典型的三條路線第一條是空 catch 塊catch 住了然后什么都不寫。這個不用多解釋屬于嚴(yán)重違規(guī)。第二條是 finally 里拋異常覆蓋原始異常前面提過。第三條是 try-with-resources 出現(xiàn)之前的古老寫法try 塊拋異常 Afinally 里 close 拋異常 BB 直接把 A 覆蓋導(dǎo)致你看到的異常是關(guān)文件失敗而真正問題可能是文件解析失敗。Java 7 之后這個問題被治本了try-with-resources 會把 close 時發(fā)生的異常作為 suppressed 附加到主異常上StackTrace 里會顯示 Suppressed: 。如果你接手的老項目還在用 finally close建議逐步改成 try-with-resources。排查異常丟失時我有一個習(xí)慣先看日志里有沒有空 catch再看 finally 里有沒有可能拋異常的代碼最后查有沒有 catch 里 return 不打印日志。按這個順序排查絕大多數(shù)異常神秘消失都能找到根源。這條經(jīng)驗在面試?yán)镏v出來比單純背誦知識點更有說服力。4.4 反射、Stream、Lambda里的異常三個高頻陷阱反射調(diào)用是異常處理的隱藏雷區(qū)。Method.invoke() 如果被調(diào)方法拋異常反射框架會把真實異常包裝成 InvocationTargetException 拋出來。你直接 catch 反射相關(guān)異常時拿到的可能是包裝殼真正原因藏在 cause 下面。我見過不止一個人 catch 到 InvocationTargetException 后打印了一下以為看到了原因其實只看到了殼。try { Method method obj.getClass().getMethod(doSomething); Object result method.invoke(obj); } catch (InvocationTargetException e) { Throwable realCause e.getCause(); // 這才是真正異常 log.error(業(yè)務(wù)方法調(diào)用失敗, realCause); }Stream API 和 Lambda 里的受檢異常處理是另一個常見問題。函數(shù)式接口的方法簽名都沒有 throws 聲明所以你在 Lambda 里直接拋受檢異常會編譯不過。常見做法有三種一是包成 RuntimeException二是自己定義一個允許受檢異常的函數(shù)式接口三是把流操作拆成傳統(tǒng) for 循環(huán)。我推薦第二種在項目公共工具類里定義這樣的接口并不復(fù)雜FunctionalInterface public interface ThrowingConsumerT { void accept(T t) throws Exception; } public static T ConsumerT unchecked(ThrowingConsumerT throwingConsumer) { return t - { try { throwingConsumer.accept(t); } catch (Exception e) { throw new RuntimeException(e); } }; }有了這個工具Stream 里的代碼就可以保持簡潔同時異常又不會靜默丟失。面試時能順勢講出這種封裝思路說明你不是第一次被 Lambda 異常坑過的人。4.5 異常鏈與initCause業(yè)務(wù)異常也要保留根因異常鏈?zhǔn)前b異常場景的技術(shù)底座。簡單說當(dāng)你在 catch 到一個底層異常后準(zhǔn)備向上拋一個業(yè)務(wù)異常這個時候一定要把底層異常作為 cause 傳進去。這樣排錯時可以通過內(nèi)層的 Caused by一步不差地追到最原始的故障點。有兩種寫法// 方式一構(gòu)造方法傳cause throw new OrderException(1001, 訂單創(chuàng)建失敗, e); // 方式二創(chuàng)建后調(diào)用initCause OrderException oe new OrderException(1001, 訂單創(chuàng)建失敗); oe.initCause(e); throw oe;需要注意的是 initCause 只能被調(diào)用一次而且如果構(gòu)造時已經(jīng)傳過 cause再調(diào) initCause 會拋 IllegalStateException。為什么要有 initCause 而不是完全靠構(gòu)造方法因為是給那些構(gòu)造方法無法預(yù)知 cause 的場景留的口子比如某些代理生成、反序列化的場景。如果你能把這個為什么有 initCause講明白面試官基本能確認(rèn)你研究過異常源碼的細(xì)節(jié)。關(guān)于異常鏈還有一個?？键cprintStackTrace 打印出的形式是 Caused by說明 JVM 在遞歸遍歷 cause 鏈。當(dāng)你做異常包裝時一定要把 getCause 鏈走完不要只看最外層異常。很多線上問題定位慢就是只看第一行堆棧沒往下翻 Caused by。5. 面試現(xiàn)場的實際體感最后再說幾句帶人這些年我面試過的候選人少說也上百了。我最直觀的感受是異常題能不能答出層次基本能判斷一個人平時寫代碼有沒有思考的習(xí)慣。背下這20道經(jīng)典面試題只是第一步更重要的是每道題背后的設(shè)計理由和工程選擇。真正讓人印象深刻的候選人往往會在回答里加一句這個坑我在生產(chǎn)環(huán)境踩過……哪怕講的是個很小的例子也比干巴巴背課本強得多。最后分享一個小建議準(zhǔn)備 Java 異常面試時別只坐在椅子上看面經(jīng)。花一個下午把這20道題涉及的代碼挨個寫一遍用 debugger 看執(zhí)行流程親手驗證 finally 覆蓋返回值、異常鏈的 Caused by、try-with-resources 的 suppressed。眼見為實之后你對異常機制的理解會進入到另一個層次面試時也能講得更從容。