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