)
寫Java也寫了十個年頭了異常處理這個話題每年都會翻出來聊但每次看新人的代碼還是會頭皮發(fā)麻。有的把異常當擺設(shè)catch完打一行日志就當無事發(fā)生有的把異常當萬能藥任何業(yè)務(wù)分支都用拋異常解決。異常處理不是Java語法里最難的那一坨但絕對是最能看出一個程序員功底的地方也是面試必問、上線必踩的環(huán)節(jié)。這篇內(nèi)容我打算系統(tǒng)地把Java異常處理從頭到尾捋一遍從異常體系本身到底層機制從實戰(zhàn)策略到性能考量再到高頻問題的排查思路。無論你是剛學Java準備面試的在校生還是工作中時不時被線上異常困擾的初級開發(fā)甚至是想幫團隊定一套異常規(guī)范的組長這篇都能給你一些可以直接用的東西。1. 異常體系全景先搞清楚Java到底把“錯誤”分成了幾類很多初學者看了不少異常處理的代碼但問起Throwable和Exception、Error之間的關(guān)系還是說不明白。這個搞不清楚后面設(shè)計異常和處理策略都會跑偏。1.1 Throwable家族不要把Error當Exception來處理先看最頂層的Throwable這是Java里所有“可以被拋出”的對象的共同父類下面分了兩大派系Error和Exception。Error表示的是JVM層面的嚴重問題比如OutOfMemoryError、StackOverflowError、NoClassDefFoundError。這類問題基本不是你的代碼能“捕獲后恢復”的捕獲了也沒用因為程序此時大概率已經(jīng)處于半癱瘓狀態(tài)。所以常規(guī)處理原則就一句話不要在代碼里捕獲Error也不要去處理它讓它直接冒泡讓JVM和應(yīng)用進程一起完蛋然后靠監(jiān)控報警去拉起來。我還有一點要特別提醒catch (Throwable t)這種寫法在大項目里幾乎等于定時炸彈。Throwable是連Error一起捕獲的有些監(jiān)控框架會用它來做兜底記錄但如果你在業(yè)務(wù)代碼里寫這種捕獲就等于把OOM也一并吞了后面出現(xiàn)詭異的內(nèi)存問題排查起來非常痛苦。Exception是程序運行中可恢復、可處理的問題比如文件找不到、網(wǎng)絡(luò)超時、參數(shù)不合法。這才是我們?nèi)粘Ｒ攸c關(guān)注的。1.2 受檢異常與非受檢異常語法規(guī)定背后的歷史包袱Exception又進一步分成兩類受檢異常Checked Exception和非受檢異常Unchecked Exception。受檢異常是編譯器強制要求你處理的典型就是IOException、SQLException。如果你調(diào)用了一個會拋受檢異常的方法你就必須“聲明throws”或者“try-catch”否則代碼編譯不過去。這個設(shè)計是Java早期的理念認為程序應(yīng)當對可預見的錯誤顯式處理。但后來的實踐表明這個設(shè)計過度理想化了——很多時候你根本沒法在當前位置處理這個異常卻還是被逼著寫了一堆try-catch最后只是把異常包一層又拋出去純屬增加噪音。非受檢異常就是RuntimeException的子類以及Error。這類異常編譯器不管你可以選擇不捕獲。NullPointerException、IllegalArgumentException、ClassCastException、IndexOutOfBoundsException都屬于這一類。它們代表的通常是編程邏輯錯誤或前置條件未滿足本來就該在代碼層面提前規(guī)避而不是依賴運行時的異常處理機制。有個非常關(guān)鍵的區(qū)別需要理解Spring事務(wù)默認只在RuntimeException非受檢時回滾受檢異常默認不回滾。這個特性讓后來絕大多數(shù)Java框架更傾向于使用RuntimeException。所以現(xiàn)在寫Java新代碼里基本不推薦自定義受檢異常除非你明確知道調(diào)用方必須處理。1.3 自定義異常應(yīng)該怎么選父類自定義異常是項目中不可避免的。你總會需要一個BizException或者BusinessException來表示業(yè)務(wù)規(guī)則被違反。我的建議是業(yè)務(wù)異常統(tǒng)一繼承RuntimeException。理由主要有三個。第一因為Spring事務(wù)默認回滾不會出現(xiàn)事務(wù)提交了一半結(jié)果的情況。第二不用在每個業(yè)務(wù)方法上逼著調(diào)用方聲明throws代碼更干凈。第三可以通過異常類型做統(tǒng)一攔截比如在ControllerAdvice里統(tǒng)一處理成錯誤碼返回給前端。繼承層次不要太深統(tǒng)一一個頂層業(yè)務(wù)異常類就夠了。如果確實需要細分可以考慮用異常內(nèi)部的錯誤碼枚舉來區(qū)分而不是搞出一堆異常子類。我見過有些項目里業(yè)務(wù)異常子類幾十個維護起來非常麻煩新增一個錯誤場景就要新建一個類。2. 核心機制解析try、catch、finally和try-with-resources的深層邏輯異常處理語法本身不復雜但真正用好的不多。這一章我重點拆解幾個容易出問題的機制細節(jié)。2.1 try-catch-finally執(zhí)行順序與finally陷阱正常場景下try塊里代碼順序執(zhí)行一旦拋出異常直接跳到對應(yīng)的catch塊無論是否發(fā)生異常finally塊都會執(zhí)行。這個大家都懂但下面幾個邊界場景很容易踩坑。第一個陷阱是finally里的return。如果try或catch里有return語句而finally里也有return那么finally里的return會覆蓋前面的返回值。更離譜的是如果finally里拋出了異常try和catch里原本的異常會被完全掩蓋。這類代碼在code review時一定要直接打回finally塊里只做清理資源這類工作不要return、不要throw。第二個陷阱是System.exit()。如果在try塊里調(diào)用了System.exit()JVM進程直接終止finally塊不會執(zhí)行。有些同學面試會被問“finally一定執(zhí)行嗎”標準答案就是要排除JVM退出和線程中斷這類場景。第三個陷阱是catch的順序。多個catch塊時子類異常必須放在父類異常前面否則編譯器直接報錯。比如catch (IOException e)必須在catch (Exception e)前面。道理其實很簡單異常匹配是自上而下找第一個能匹配的catch塊如果先寫了父類子類異常就被父類“截胡”了。try { // 業(yè)務(wù)代碼... } catch (FileNotFoundException e) { // 更具體的處理邏輯 } catch (IOException e) { // 更通用的IO處理邏輯 }2.2 try-with-resources資源關(guān)閉的標準答案如果你還在用finally去關(guān)閉流或數(shù)據(jù)庫連接我建議把這段看完。Java 7引入的try-with-resources才是資源關(guān)閉的標準姿勢它要求資源類實現(xiàn)AutoCloseable接口InputStream、OutputStream、Connection這些都實現(xiàn)了。讓我用一個非常實際的多資源場景來演示。以前要正確關(guān)閉兩個流必須寫嵌套的try-finally還得處理各自的異常代碼又長又容易出錯// 推薦寫法try-with-resources多個資源用分號分隔 try (InputStream input new FileInputStream(input.txt); OutputStream output new FileOutputStream(output.txt)) { byte[] buffer new byte[1024]; int len; while ((len input.read(buffer)) ! -1) { output.write(buffer, 0, len); } }你不需要手動close編譯器會自動生成關(guān)閉邏輯而且關(guān)閉順序是逆序的后聲明先關(guān)閉對應(yīng)先開output再關(guān)output再關(guān)input。還有一點做得非常講究如果try塊和close方法都拋出了異常Java會優(yōu)先保留try塊里的原始異常同時把close階段拋出的異常作為“被抑制異?！睊斓皆籍惓Ｉ?。你可以用getSuppressed()方法拿到它們。這樣排查問題時不會被莫名其妙的關(guān)閉異常干擾主方向這個設(shè)計值得手動點贊。2.3 throw與throws異常是怎么傳播上來的throws是方法聲明的一部分表示“我這個方法可能拋出這個異常調(diào)用方自己要心里有數(shù)”。throw則是主動拋出一個異常實例。兩者動作不同但經(jīng)常在一段代碼里配合出現(xiàn)。傳播規(guī)則是這樣的異常從最先發(fā)生的地方逐層往外拋如果每一層都不捕獲最終會到達線程的頂層處理器。對于主線程異常會直接導致程序退出并打印堆棧。對于線程池里的線程情況要復雜一些這個后面會單獨說。有個最佳實踐要強調(diào)在做異常轉(zhuǎn)換和包裝的時候一定要保留原始堆棧。比如你寫throw new BizException(庫存不足, e);這個構(gòu)造方式會把e作為cause傳進去。而你寫成“手動拼接消息”的話throw new BizException(庫存不足: e.getMessage());就丟失了原始異常的完整堆棧排查問題時幾乎等于廢掉了一條重要線索。所以永遠記住cause參數(shù)必須傳這是異常處理最基本的職業(yè)素養(yǎng)。3. 實戰(zhàn)中的異常處理策略什么時候捕獲、什么時候拋出、什么時候自定義機制明白了真正難的是策略。異常處理本質(zhì)上是“在哪里處理最合適”的問題處理早了破壞封裝處理晚了又容易堆滿日志。3.1 捕獲粒度別在底層捕獲你處理不了的異常新手最常見的錯誤是在方法內(nèi)部把異常catch掉再打一行日志然后繼續(xù)往下走。這種“假裝處理”的代碼是最毒的因為程序返回值或后續(xù)邏輯很可能已經(jīng)處在一個錯誤狀態(tài)但表面上一片安靜等到數(shù)據(jù)錯亂了才顯示出問題。核心原則是在當前這個層級能做出有效應(yīng)對才捕獲如果不能就往上拋。什么叫有效應(yīng)對比如你寫的是接口的入口層那你可以捕獲業(yè)務(wù)異常并轉(zhuǎn)換為約定的錯誤碼返回給前端比如你寫的是定時任務(wù)批處理那你可以捕獲單條數(shù)據(jù)的異常并標注這批次里哪些數(shù)據(jù)失敗繼續(xù)處理后面的數(shù)據(jù)。這些都是有效應(yīng)對。如果只是中間層做數(shù)據(jù)組裝、調(diào)用外部服務(wù)、讀文件你沒有能力決定“失敗后對用戶說什么”那就別捕獲讓異常繼續(xù)往上走由統(tǒng)一出口處理。3.2 自定義業(yè)務(wù)異常與錯誤碼別一股腦拋Exception自定義業(yè)務(wù)異常的核心價值是讓錯誤信息結(jié)構(gòu)化。一個合格的自定義異常要能表達三層信息發(fā)生了什么、影響誰、具體是哪個上下文。我常用的做法是定義一個帶錯誤碼枚舉的BizException再加一個字段用來攜帶上下文數(shù)據(jù)。比如一個導入訂單的功能拋出異常時除了錯誤碼還可以把失敗的那一行數(shù)據(jù)一起帶上。這樣統(tǒng)一處理時能直接把“第xx行數(shù)據(jù)不合法”這樣的提示返回給前端。public class BizException extends RuntimeException { private final ErrorCode errorCode; private final String context; public BizException(ErrorCode errorCode, String context) { super(String.format(%s: %s, errorCode.getMessage(), context)); this.errorCode errorCode; this.context context; } // getter省略... }這里有一個細節(jié)異常message要包含足夠的參數(shù)方便日志排查。我經(jīng)?？吹接腥藪伋霎惓r只寫“參數(shù)錯誤”日志里根本不知道是哪個參數(shù)錯了、值是多少。能把參數(shù)值拼進異常消息就能省掉很多日后的“考古工作”。3.3 異常日志規(guī)范同樣一段代碼日志價值天差地別異常處理和日志是伴生關(guān)系處理得再好日志打不好線上問題一樣抓瞎。先說不好的寫法。第一種是 catch 后只打一行e.getMessage()然后當作沒事。第二種是log.error(error)不帶任何異常對象。第三種是printStackTrace()把堆棧打到標準輸出一旦線上系統(tǒng)把stdout重定向到別的文件你根本不知道日志去哪了而且這種寫法在分布式系統(tǒng)里完全無法和請求鏈路關(guān)聯(lián)。推薦的做法是用日志框架的占位符并且在最后一個參數(shù)傳入異常對象這樣框架會自動打完整堆棧try { orderService.createOrder(orderDTO); } catch (BizException e) { log.error(創(chuàng)建訂單失敗, userId{}, orderNo{}, userId, orderNo, e); throw e; }這段日志的價值在于不但知道“創(chuàng)建訂單失敗”這個事實還有userId、orderNo這種排查問題的錨點最后還有完整異常堆棧。如果業(yè)務(wù)里還接入了traceId那就更完美了一個鏈路上下游的異常都能串起來。4. 性能與并發(fā)場景異常處理不能拖垮系統(tǒng)“性能”這個詞大部分人是不會第一時間和異常處理聯(lián)系在一起的但等你的系統(tǒng)上了量級異常的性能開銷就會變得非常明顯。4.1 為什么異常創(chuàng)建比普通對象創(chuàng)建貴異常的昂貴之處不在try-catch本身而在throw new的那一刻。JVM在創(chuàng)建異常對象時要填充線程當前調(diào)用棧也就是抓取棧幀快照這個操作比普通new一個Object高出兩三個數(shù)量級。更致命的是如果你在循環(huán)里頻繁拋出異常這個開銷會被放大幾十倍。所以實戰(zhàn)里有一條鐵律不要用異常做控制流。我見過有人用NumberFormatException來判斷字符串是不是數(shù)字用ArrayIndexOutOfBoundsException來檢測數(shù)組結(jié)束這些都屬于典型的錯誤示范。正確做法是直接用正則、Character.isDigit()或顯式判斷。// 反例異?？刂屏?try { int val Integer.parseInt(str); } catch (NumberFormatException e) { // 認為不是數(shù)字 }如果你確實要對所有字符串做轉(zhuǎn)換并容忍非法值可以在高頻路徑上用“前置校驗parse”組合或者干脆在外面catch但內(nèi)部已經(jīng)限定了這個方法的調(diào)用頻率?？傊惓Ｊ墙o“不該發(fā)生但發(fā)生了”的情況準備的不是給“預期會發(fā)生”的事情準備的分支邏輯。4.2 批量處理中的異常隔離一條壞數(shù)據(jù)不應(yīng)該帶崩整批批處理是異常設(shè)計最容易失衡的場景。一條臟數(shù)據(jù)拋個異常如果沒處理好整批任務(wù)戛然而止之前處理完的幾千條全部白做。但如果每條都捕獲、打印堆棧那日志量和CPU開銷又不劃算。正確設(shè)計思路是把單條捕獲和失敗收集結(jié)合起來循環(huán)內(nèi)逐條捕獲收集錯誤到List不中斷批量循環(huán)外根據(jù)錯誤數(shù)量決定是繼續(xù)還是告警。同時日志層面要做降噪相同錯誤碼只記錄一次完整堆棧后續(xù)只計數(shù)。ListString failMessages new ArrayList(); for (OrderDTO dto : batchList) { try { processOne(dto); } catch (BizException e) { failMessages.add(訂單 dto.getOrderNo() 失敗: e.getMessage()); } } if (!failMessages.isEmpty()) { alarmService.sendBatchWarn(batchId, failMessages.size(), failMessages.stream().limit(20).collect(Collectors.toList())); }還有個經(jīng)驗批處理里最怕的是“無差別異常捕獲”把程序Bug也當作業(yè)務(wù)失敗一樣吞掉。我的建議是只catch預期的BizException和明顯的可恢復異常對于RuntimeException跑出來的程序缺陷應(yīng)該讓它中斷一次打出一個完整堆棧然后修復代碼而不是偽裝成一條失敗記錄繼續(xù)跑。4.3 線程池和異步任務(wù)中的異常處理異常不會自動消失只會自動被吃掉用線程池的時候有個普遍誤區(qū)以為任務(wù)里的異常會自動像主線程那樣打印出來。其實Exception在execute()方式提交的任務(wù)里會被線程池的run()方法捕獲然后靜默丟棄。也就是說你在業(yè)務(wù)代碼里沒捕獲的異常線上日志里什么都看不到任務(wù)看起來是“沒報錯”地消失了。這非常危險。如果你用ExecutorService的execute(Runnable)提交任務(wù)一定記得給線程池設(shè)置一個UncaughtExceptionHandler作為全局兜底日志。如果你用的是submit(Callable)任務(wù)里的異常會被存儲在Future內(nèi)部必須調(diào)用future.get()才會被重新拋出。所以submit之后最好結(jié)合Future的get結(jié)果統(tǒng)一處理別調(diào)了submit就徹底不管了。ThreadPoolExecutorExecutor pool new ThreadPoolExecutor( 4, 8, 60, TimeUnit.SECONDS, new LinkedBlockingQueue(1000), new NamedThreadFactory(order-async), new ThreadPoolExecutor.AbortPolicy() ); pool.setUncaughtExceptionHandler((t, e) - log.error(線程池任務(wù)異常, thread{}, t.getName(), e));5. 常見問題速查與排查技巧實錄與其把每個異常類都背一遍不如掌握一套排查思路。我在這一章里把高頻異常整理成一份速查表再結(jié)合真實案例講講排查鏈路。5.1 高頻異常案例NPE、ClassCastException、IndexOutOfBoundsNullPointerException在所有線上異常里排第一。排查NPE的核心是讀堆棧Java高版本會精確提示“Cannot invoke xxx because the return value of xxx is null”直接定位是哪個調(diào)用null了。如果堆棧信息里看不出來最快的辦法是在IDE里設(shè)置 “NPE breakpoint”開啟斷點條件后異常拋出的那一瞬間就能看到當前作用域里每個變量的值。它最讓人頭疼的是各種“偽裝NPE”比如Stream里map中調(diào)用方法返回null后續(xù)reduce直接炸。規(guī)避思路無非兩個要么源頭杜絕用Optional Objects.requireNonNull盡早暴露要么在邊界防御對關(guān)鍵接收對象做isNull判斷。ClassCastException通常不是“強轉(zhuǎn)錯類型”而是類加載器問題或泛型擦除帶來的假象。我遇到過的情況包括不同jar包帶了同一個類的不同版本代碼里強轉(zhuǎn)成另一個ClassLoader加載的版本直接ClassCastException。排查時除了看堆棧還要看是哪個ClassLoader加載的這兩個類。至于IndexOutOfBoundsException常見于遍歷時刪元素、計算數(shù)組索引越界處理原則是“用迭代器刪除、無把握就用for倒序或stream filter”。速查表整理如下異常類型常見誘因排查重點NullPointerException調(diào)用鏈中某個中間值為null高版本直接看堆棧提示是哪個方法調(diào)用導致ClassCastException強轉(zhuǎn)類型不匹配、類加載器不一致加JVM參數(shù)打印類加載器確認jar版本IndexOutOfBoundsException集合動態(tài)修改、索引計算錯誤檢查循環(huán)下標、刪除操作方式IllegalArgumentException參數(shù)校驗失敗但被忽略看是否進入異?？刂屏鞯腻e誤場景OutOfMemoryError堆內(nèi)存泄漏或堆參數(shù)過小dump堆再分析大對象、GC Roots引用鏈5.2 用堆棧信息定位問題的“Caused by”才是關(guān)鍵排查異常的第一個動作不是看第一行而是看完整的堆棧鏈特別是Caused by后面的部分。尤其在異常被層層包裝后只有追到根因才能真正解決問題。我舉個例子一個調(diào)用第三方接口的服務(wù)一直報BizException面上消息是“調(diào)用超時”。表面看是接口問題但繼續(xù)往下翻Caused by是SocketTimeoutException再往下還有一層Caused by是DNS解析超時。真正要處理的是DNS服務(wù)器速度而不是給接口超時加長。如果只看第一層這個問題永遠解決不了。所以我在團隊里反復強調(diào)“看堆棧只看到Error Line就開始回復這是最不專業(yè)的排查方式?！?至少要看完整堆棧的caused by鏈。5.3 線上異常排查的完整鏈路traceId 日志級別 分組告警線上問題比本地復現(xiàn)難得多核心武器是鏈路追蹤和日志。一個請求從網(wǎng)關(guān)進入后都會由框架生成traceId并塞進MDC。這樣一條請求在多個服務(wù)間的所有日志都帶著同一個traceId用grep一拉就能還原整條鏈路。異常排查最基礎(chǔ)的操作就是報錯發(fā)生時先用異常信息里的關(guān)鍵字搜traceId再把這條traceId的所有日志按時間順序捋一遍。日志級別這里也要有講究。不要把業(yè)務(wù)異常的ERROR級別當洪水猛獸在批量任務(wù)中一條數(shù)據(jù)失敗是正常情況級別應(yīng)該用WARN只有整批失敗、服務(wù)不可用、內(nèi)存異常才應(yīng)該用ERROR。不然日志系統(tǒng)里全是ERROR真正嚴重的問題反而不容易區(qū)分。告警這塊我建議按異常類型分組而不是按服務(wù)維度無腦觸發(fā)。BizException可以單獨設(shè)置低頻告警NPE和類轉(zhuǎn)換異常這類程序Bug可以整頁郵件告警Infrastructure異常網(wǎng)絡(luò)超時、數(shù)據(jù)庫連接池打滿要走獨立的高優(yōu)告警通道。6. 團隊規(guī)范與異常處理的長期修養(yǎng)很多人以為異常處理是“語法技巧”但一個項目里異常處理好不好更多取決于團隊有沒有形成一致的規(guī)范。有些原則是靠日積月累沉淀出來的。6.1 異常處理相關(guān)的團隊規(guī)約寧可少吞不可多寫我參與過的幾個項目都定了一些異常相關(guān)的規(guī)約核心大致是禁止捕獲異常后不處理、不輸出、不重新拋出。實現(xiàn)了“處理”就一定要有動作。禁止捕獲Exception后只打e.getMessage()不打堆棧。禁止用異?？刂茦I(yè)務(wù)流程比如用parse異常當校驗分支。禁止在循環(huán)中創(chuàng)建、拋出、捕獲異常來做分支判斷。業(yè)務(wù)異常必須使用統(tǒng)一異常類和統(tǒng)一錯誤碼禁止直接拋new RuntimeException(中文提示)。禁止在finally里return或throw這是代碼review必掛項。這些規(guī)約不是教條每條背后都有一次深刻的線上事故或者繁瑣排查的教訓換來的。6.2 從“會用異常”到“設(shè)計異?！毕裨O(shè)計API一樣設(shè)計你的異常更高一層的異常處理能力是把異常當作API的一部分來設(shè)計。這就意味著異常類型名要說明問題本質(zhì)比如OrderExpiredException而不是BizException 105異常message要有可操作性異常里要能帶上下文參數(shù)調(diào)用方要能從異常中知道下一步該怎么處理。比如一個支付回調(diào)接口拋出的異常類型如果叫PaymentStatusMismatchException里面有orderId、currentStatus、expectedStatus調(diào)用方一看就知道是狀態(tài)流轉(zhuǎn)不對而不是一頭霧水地再去查數(shù)據(jù)庫。好的異常設(shè)計能顯著減少跨部門扯皮尤其在對接第三方系統(tǒng)時異常信息越明確聯(lián)調(diào)效率就越高。6.3 最后再分享一個真正值錢的經(jīng)驗從我個人經(jīng)驗來說排查異常時最容易犯的錯誤是過度依賴異常本身而忽略了正常路徑下的上下文現(xiàn)場。異常只是“結(jié)果先生留下的通知”真正的問題往往發(fā)生在拋異常之前的幾步。比如數(shù)組越界越界只是結(jié)果循環(huán)邊界算錯了才是根因校驗失敗只是結(jié)果數(shù)據(jù)是怎么被污染的才是根因。所以我現(xiàn)在排查異常時會養(yǎng)成一個習慣不僅看異常堆棧還要順著日志往前翻30秒看看異常發(fā)生前這個請求都經(jīng)歷了什么。絕大多數(shù)詭異問題的答案其實都在那段“看似正?！钡娜罩纠?。這也是我把異常處理定義為“長期修養(yǎng)”的原因——它不是幾個語法點而是一整套排查問題、設(shè)計代碼的思維方式。 Java異常處理全攻略：體系、機制、性能與排查實戰(zhàn)
寫Java也寫了十個年頭了異常處理這個話題每年都會翻出來聊但每次看新人的代碼還是會頭皮發(fā)麻。有的把異常當擺設(shè)catch完打一行日志就當無事發(fā)生有的把異常當萬能藥任何業(yè)務(wù)分支都用拋異常解決。異常處理不是Java語法里最難的那一坨但絕對是最能看出一個程序員功底的地方也是面試必問、上線必踩的環(huán)節(jié)。這篇內(nèi)容我打算系統(tǒng)地把Java異常處理從頭到尾捋一遍從異常體系本身到底層機制從實戰(zhàn)策略到性能考量再到高頻問題的排查思路。無論你是剛學Java準備面試的在校生還是工作中時不時被線上異常困擾的初級開發(fā)甚至是想幫團隊定一套異常規(guī)范的組長這篇都能給你一些可以直接用的東西。1. 異常體系全景先搞清楚Java到底把“錯誤”分成了幾類很多初學者看了不少異常處理的代碼但問起Throwable和Exception、Error之間的關(guān)系還是說不明白。這個搞不清楚后面設(shè)計異常和處理策略都會跑偏。1.1 Throwable家族不要把Error當Exception來處理先看最頂層的Throwable這是Java里所有“可以被拋出”的對象的共同父類下面分了兩大派系Error和Exception。Error表示的是JVM層面的嚴重問題比如OutOfMemoryError、StackOverflowError、NoClassDefFoundError。這類問題基本不是你的代碼能“捕獲后恢復”的捕獲了也沒用因為程序此時大概率已經(jīng)處于半癱瘓狀態(tài)。所以常規(guī)處理原則就一句話不要在代碼里捕獲Error也不要去處理它讓它直接冒泡讓JVM和應(yīng)用進程一起完蛋然后靠監(jiān)控報警去拉起來。我還有一點要特別提醒catch (Throwable t)這種寫法在大項目里幾乎等于定時炸彈。Throwable是連Error一起捕獲的有些監(jiān)控框架會用它來做兜底記錄但如果你在業(yè)務(wù)代碼里寫這種捕獲就等于把OOM也一并吞了后面出現(xiàn)詭異的內(nèi)存問題排查起來非常痛苦。Exception是程序運行中可恢復、可處理的問題比如文件找不到、網(wǎng)絡(luò)超時、參數(shù)不合法。這才是我們?nèi)粘Ｒ攸c關(guān)注的。1.2 受檢異常與非受檢異常語法規(guī)定背后的歷史包袱Exception又進一步分成兩類受檢異常Checked Exception和非受檢異常Unchecked Exception。受檢異常是編譯器強制要求你處理的典型就是IOException、SQLException。如果你調(diào)用了一個會拋受檢異常的方法你就必須“聲明throws”或者“try-catch”否則代碼編譯不過去。這個設(shè)計是Java早期的理念認為程序應(yīng)當對可預見的錯誤顯式處理。但后來的實踐表明這個設(shè)計過度理想化了——很多時候你根本沒法在當前位置處理這個異常卻還是被逼著寫了一堆try-catch最后只是把異常包一層又拋出去純屬增加噪音。非受檢異常就是RuntimeException的子類以及Error。這類異常編譯器不管你可以選擇不捕獲。NullPointerException、IllegalArgumentException、ClassCastException、IndexOutOfBoundsException都屬于這一類。它們代表的通常是編程邏輯錯誤或前置條件未滿足本來就該在代碼層面提前規(guī)避而不是依賴運行時的異常處理機制。有個非常關(guān)鍵的區(qū)別需要理解Spring事務(wù)默認只在RuntimeException非受檢時回滾受檢異常默認不回滾。這個特性讓后來絕大多數(shù)Java框架更傾向于使用RuntimeException。所以現(xiàn)在寫Java新代碼里基本不推薦自定義受檢異常除非你明確知道調(diào)用方必須處理。1.3 自定義異常應(yīng)該怎么選父類自定義異常是項目中不可避免的。你總會需要一個BizException或者BusinessException來表示業(yè)務(wù)規(guī)則被違反。我的建議是業(yè)務(wù)異常統(tǒng)一繼承RuntimeException。理由主要有三個。第一因為Spring事務(wù)默認回滾不會出現(xiàn)事務(wù)提交了一半結(jié)果的情況。第二不用在每個業(yè)務(wù)方法上逼著調(diào)用方聲明throws代碼更干凈。第三可以通過異常類型做統(tǒng)一攔截比如在ControllerAdvice里統(tǒng)一處理成錯誤碼返回給前端。繼承層次不要太深統(tǒng)一一個頂層業(yè)務(wù)異常類就夠了。如果確實需要細分可以考慮用異常內(nèi)部的錯誤碼枚舉來區(qū)分而不是搞出一堆異常子類。我見過有些項目里業(yè)務(wù)異常子類幾十個維護起來非常麻煩新增一個錯誤場景就要新建一個類。2. 核心機制解析try、catch、finally和try-with-resources的深層邏輯異常處理語法本身不復雜但真正用好的不多。這一章我重點拆解幾個容易出問題的機制細節(jié)。2.1 try-catch-finally執(zhí)行順序與finally陷阱正常場景下try塊里代碼順序執(zhí)行一旦拋出異常直接跳到對應(yīng)的catch塊無論是否發(fā)生異常finally塊都會執(zhí)行。這個大家都懂但下面幾個邊界場景很容易踩坑。第一個陷阱是finally里的return。如果try或catch里有return語句而finally里也有return那么finally里的return會覆蓋前面的返回值。更離譜的是如果finally里拋出了異常try和catch里原本的異常會被完全掩蓋。這類代碼在code review時一定要直接打回finally塊里只做清理資源這類工作不要return、不要throw。第二個陷阱是System.exit()。如果在try塊里調(diào)用了System.exit()JVM進程直接終止finally塊不會執(zhí)行。有些同學面試會被問“finally一定執(zhí)行嗎”標準答案就是要排除JVM退出和線程中斷這類場景。第三個陷阱是catch的順序。多個catch塊時子類異常必須放在父類異常前面否則編譯器直接報錯。比如catch (IOException e)必須在catch (Exception e)前面。道理其實很簡單異常匹配是自上而下找第一個能匹配的catch塊如果先寫了父類子類異常就被父類“截胡”了。try { // 業(yè)務(wù)代碼... } catch (FileNotFoundException e) { // 更具體的處理邏輯 } catch (IOException e) { // 更通用的IO處理邏輯 }2.2 try-with-resources資源關(guān)閉的標準答案如果你還在用finally去關(guān)閉流或數(shù)據(jù)庫連接我建議把這段看完。Java 7引入的try-with-resources才是資源關(guān)閉的標準姿勢它要求資源類實現(xiàn)AutoCloseable接口InputStream、OutputStream、Connection這些都實現(xiàn)了。讓我用一個非常實際的多資源場景來演示。以前要正確關(guān)閉兩個流必須寫嵌套的try-finally還得處理各自的異常代碼又長又容易出錯// 推薦寫法try-with-resources多個資源用分號分隔 try (InputStream input new FileInputStream(input.txt); OutputStream output new FileOutputStream(output.txt)) { byte[] buffer new byte[1024]; int len; while ((len input.read(buffer)) ! -1) { output.write(buffer, 0, len); } }你不需要手動close編譯器會自動生成關(guān)閉邏輯而且關(guān)閉順序是逆序的后聲明先關(guān)閉對應(yīng)先開output再關(guān)output再關(guān)input。還有一點做得非常講究如果try塊和close方法都拋出了異常Java會優(yōu)先保留try塊里的原始異常同時把close階段拋出的異常作為“被抑制異?！睊斓皆籍惓Ｉ?。你可以用getSuppressed()方法拿到它們。這樣排查問題時不會被莫名其妙的關(guān)閉異常干擾主方向這個設(shè)計值得手動點贊。2.3 throw與throws異常是怎么傳播上來的throws是方法聲明的一部分表示“我這個方法可能拋出這個異常調(diào)用方自己要心里有數(shù)”。throw則是主動拋出一個異常實例。兩者動作不同但經(jīng)常在一段代碼里配合出現(xiàn)。傳播規(guī)則是這樣的異常從最先發(fā)生的地方逐層往外拋如果每一層都不捕獲最終會到達線程的頂層處理器。對于主線程異常會直接導致程序退出并打印堆棧。對于線程池里的線程情況要復雜一些這個后面會單獨說。有個最佳實踐要強調(diào)在做異常轉(zhuǎn)換和包裝的時候一定要保留原始堆棧。比如你寫throw new BizException(庫存不足, e);這個構(gòu)造方式會把e作為cause傳進去。而你寫成“手動拼接消息”的話throw new BizException(庫存不足: e.getMessage());就丟失了原始異常的完整堆棧排查問題時幾乎等于廢掉了一條重要線索。所以永遠記住cause參數(shù)必須傳這是異常處理最基本的職業(yè)素養(yǎng)。3. 實戰(zhàn)中的異常處理策略什么時候捕獲、什么時候拋出、什么時候自定義機制明白了真正難的是策略。異常處理本質(zhì)上是“在哪里處理最合適”的問題處理早了破壞封裝處理晚了又容易堆滿日志。3.1 捕獲粒度別在底層捕獲你處理不了的異常新手最常見的錯誤是在方法內(nèi)部把異常catch掉再打一行日志然后繼續(xù)往下走。這種“假裝處理”的代碼是最毒的因為程序返回值或后續(xù)邏輯很可能已經(jīng)處在一個錯誤狀態(tài)但表面上一片安靜等到數(shù)據(jù)錯亂了才顯示出問題。核心原則是在當前這個層級能做出有效應(yīng)對才捕獲如果不能就往上拋。什么叫有效應(yīng)對比如你寫的是接口的入口層那你可以捕獲業(yè)務(wù)異常并轉(zhuǎn)換為約定的錯誤碼返回給前端比如你寫的是定時任務(wù)批處理那你可以捕獲單條數(shù)據(jù)的異常并標注這批次里哪些數(shù)據(jù)失敗繼續(xù)處理后面的數(shù)據(jù)。這些都是有效應(yīng)對。如果只是中間層做數(shù)據(jù)組裝、調(diào)用外部服務(wù)、讀文件你沒有能力決定“失敗后對用戶說什么”那就別捕獲讓異常繼續(xù)往上走由統(tǒng)一出口處理。3.2 自定義業(yè)務(wù)異常與錯誤碼別一股腦拋Exception自定義業(yè)務(wù)異常的核心價值是讓錯誤信息結(jié)構(gòu)化。一個合格的自定義異常要能表達三層信息發(fā)生了什么、影響誰、具體是哪個上下文。我常用的做法是定義一個帶錯誤碼枚舉的BizException再加一個字段用來攜帶上下文數(shù)據(jù)。比如一個導入訂單的功能拋出異常時除了錯誤碼還可以把失敗的那一行數(shù)據(jù)一起帶上。這樣統(tǒng)一處理時能直接把“第xx行數(shù)據(jù)不合法”這樣的提示返回給前端。public class BizException extends RuntimeException { private final ErrorCode errorCode; private final String context; public BizException(ErrorCode errorCode, String context) { super(String.format(%s: %s, errorCode.getMessage(), context)); this.errorCode errorCode; this.context context; } // getter省略... }這里有一個細節(jié)異常message要包含足夠的參數(shù)方便日志排查。我經(jīng)?？吹接腥藪伋霎惓r只寫“參數(shù)錯誤”日志里根本不知道是哪個參數(shù)錯了、值是多少。能把參數(shù)值拼進異常消息就能省掉很多日后的“考古工作”。3.3 異常日志規(guī)范同樣一段代碼日志價值天差地別異常處理和日志是伴生關(guān)系處理得再好日志打不好線上問題一樣抓瞎。先說不好的寫法。第一種是 catch 后只打一行e.getMessage()然后當作沒事。第二種是log.error(error)不帶任何異常對象。第三種是printStackTrace()把堆棧打到標準輸出一旦線上系統(tǒng)把stdout重定向到別的文件你根本不知道日志去哪了而且這種寫法在分布式系統(tǒng)里完全無法和請求鏈路關(guān)聯(lián)。推薦的做法是用日志框架的占位符并且在最后一個參數(shù)傳入異常對象這樣框架會自動打完整堆棧try { orderService.createOrder(orderDTO); } catch (BizException e) { log.error(創(chuàng)建訂單失敗, userId{}, orderNo{}, userId, orderNo, e); throw e; }這段日志的價值在于不但知道“創(chuàng)建訂單失敗”這個事實還有userId、orderNo這種排查問題的錨點最后還有完整異常堆棧。如果業(yè)務(wù)里還接入了traceId那就更完美了一個鏈路上下游的異常都能串起來。4. 性能與并發(fā)場景異常處理不能拖垮系統(tǒng)“性能”這個詞大部分人是不會第一時間和異常處理聯(lián)系在一起的但等你的系統(tǒng)上了量級異常的性能開銷就會變得非常明顯。4.1 為什么異常創(chuàng)建比普通對象創(chuàng)建貴異常的昂貴之處不在try-catch本身而在throw new的那一刻。JVM在創(chuàng)建異常對象時要填充線程當前調(diào)用棧也就是抓取棧幀快照這個操作比普通new一個Object高出兩三個數(shù)量級。更致命的是如果你在循環(huán)里頻繁拋出異常這個開銷會被放大幾十倍。所以實戰(zhàn)里有一條鐵律不要用異常做控制流。我見過有人用NumberFormatException來判斷字符串是不是數(shù)字用ArrayIndexOutOfBoundsException來檢測數(shù)組結(jié)束這些都屬于典型的錯誤示范。正確做法是直接用正則、Character.isDigit()或顯式判斷。// 反例異?？刂屏?try { int val Integer.parseInt(str); } catch (NumberFormatException e) { // 認為不是數(shù)字 }如果你確實要對所有字符串做轉(zhuǎn)換并容忍非法值可以在高頻路徑上用“前置校驗parse”組合或者干脆在外面catch但內(nèi)部已經(jīng)限定了這個方法的調(diào)用頻率?？傊惓Ｊ墙o“不該發(fā)生但發(fā)生了”的情況準備的不是給“預期會發(fā)生”的事情準備的分支邏輯。4.2 批量處理中的異常隔離一條壞數(shù)據(jù)不應(yīng)該帶崩整批批處理是異常設(shè)計最容易失衡的場景。一條臟數(shù)據(jù)拋個異常如果沒處理好整批任務(wù)戛然而止之前處理完的幾千條全部白做。但如果每條都捕獲、打印堆棧那日志量和CPU開銷又不劃算。正確設(shè)計思路是把單條捕獲和失敗收集結(jié)合起來循環(huán)內(nèi)逐條捕獲收集錯誤到List不中斷批量循環(huán)外根據(jù)錯誤數(shù)量決定是繼續(xù)還是告警。同時日志層面要做降噪相同錯誤碼只記錄一次完整堆棧后續(xù)只計數(shù)。ListString failMessages new ArrayList(); for (OrderDTO dto : batchList) { try { processOne(dto); } catch (BizException e) { failMessages.add(訂單 dto.getOrderNo() 失敗: e.getMessage()); } } if (!failMessages.isEmpty()) { alarmService.sendBatchWarn(batchId, failMessages.size(), failMessages.stream().limit(20).collect(Collectors.toList())); }還有個經(jīng)驗批處理里最怕的是“無差別異常捕獲”把程序Bug也當作業(yè)務(wù)失敗一樣吞掉。我的建議是只catch預期的BizException和明顯的可恢復異常對于RuntimeException跑出來的程序缺陷應(yīng)該讓它中斷一次打出一個完整堆棧然后修復代碼而不是偽裝成一條失敗記錄繼續(xù)跑。4.3 線程池和異步任務(wù)中的異常處理異常不會自動消失只會自動被吃掉用線程池的時候有個普遍誤區(qū)以為任務(wù)里的異常會自動像主線程那樣打印出來。其實Exception在execute()方式提交的任務(wù)里會被線程池的run()方法捕獲然后靜默丟棄。也就是說你在業(yè)務(wù)代碼里沒捕獲的異常線上日志里什么都看不到任務(wù)看起來是“沒報錯”地消失了。這非常危險。如果你用ExecutorService的execute(Runnable)提交任務(wù)一定記得給線程池設(shè)置一個UncaughtExceptionHandler作為全局兜底日志。如果你用的是submit(Callable)任務(wù)里的異常會被存儲在Future內(nèi)部必須調(diào)用future.get()才會被重新拋出。所以submit之后最好結(jié)合Future的get結(jié)果統(tǒng)一處理別調(diào)了submit就徹底不管了。ThreadPoolExecutorExecutor pool new ThreadPoolExecutor( 4, 8, 60, TimeUnit.SECONDS, new LinkedBlockingQueue(1000), new NamedThreadFactory(order-async), new ThreadPoolExecutor.AbortPolicy() ); pool.setUncaughtExceptionHandler((t, e) - log.error(線程池任務(wù)異常, thread{}, t.getName(), e));5. 常見問題速查與排查技巧實錄與其把每個異常類都背一遍不如掌握一套排查思路。我在這一章里把高頻異常整理成一份速查表再結(jié)合真實案例講講排查鏈路。5.1 高頻異常案例NPE、ClassCastException、IndexOutOfBoundsNullPointerException在所有線上異常里排第一。排查NPE的核心是讀堆棧Java高版本會精確提示“Cannot invoke xxx because the return value of xxx is null”直接定位是哪個調(diào)用null了。如果堆棧信息里看不出來最快的辦法是在IDE里設(shè)置 “NPE breakpoint”開啟斷點條件后異常拋出的那一瞬間就能看到當前作用域里每個變量的值。它最讓人頭疼的是各種“偽裝NPE”比如Stream里map中調(diào)用方法返回null后續(xù)reduce直接炸。規(guī)避思路無非兩個要么源頭杜絕用Optional Objects.requireNonNull盡早暴露要么在邊界防御對關(guān)鍵接收對象做isNull判斷。ClassCastException通常不是“強轉(zhuǎn)錯類型”而是類加載器問題或泛型擦除帶來的假象。我遇到過的情況包括不同jar包帶了同一個類的不同版本代碼里強轉(zhuǎn)成另一個ClassLoader加載的版本直接ClassCastException。排查時除了看堆棧還要看是哪個ClassLoader加載的這兩個類。至于IndexOutOfBoundsException常見于遍歷時刪元素、計算數(shù)組索引越界處理原則是“用迭代器刪除、無把握就用for倒序或stream filter”。速查表整理如下異常類型常見誘因排查重點NullPointerException調(diào)用鏈中某個中間值為null高版本直接看堆棧提示是哪個方法調(diào)用導致ClassCastException強轉(zhuǎn)類型不匹配、類加載器不一致加JVM參數(shù)打印類加載器確認jar版本IndexOutOfBoundsException集合動態(tài)修改、索引計算錯誤檢查循環(huán)下標、刪除操作方式IllegalArgumentException參數(shù)校驗失敗但被忽略看是否進入異?？刂屏鞯腻e誤場景OutOfMemoryError堆內(nèi)存泄漏或堆參數(shù)過小dump堆再分析大對象、GC Roots引用鏈5.2 用堆棧信息定位問題的“Caused by”才是關(guān)鍵排查異常的第一個動作不是看第一行而是看完整的堆棧鏈特別是Caused by后面的部分。尤其在異常被層層包裝后只有追到根因才能真正解決問題。我舉個例子一個調(diào)用第三方接口的服務(wù)一直報BizException面上消息是“調(diào)用超時”。表面看是接口問題但繼續(xù)往下翻Caused by是SocketTimeoutException再往下還有一層Caused by是DNS解析超時。真正要處理的是DNS服務(wù)器速度而不是給接口超時加長。如果只看第一層這個問題永遠解決不了。所以我在團隊里反復強調(diào)“看堆棧只看到Error Line就開始回復這是最不專業(yè)的排查方式?！?至少要看完整堆棧的caused by鏈。5.3 線上異常排查的完整鏈路traceId 日志級別 分組告警線上問題比本地復現(xiàn)難得多核心武器是鏈路追蹤和日志。一個請求從網(wǎng)關(guān)進入后都會由框架生成traceId并塞進MDC。這樣一條請求在多個服務(wù)間的所有日志都帶著同一個traceId用grep一拉就能還原整條鏈路。異常排查最基礎(chǔ)的操作就是報錯發(fā)生時先用異常信息里的關(guān)鍵字搜traceId再把這條traceId的所有日志按時間順序捋一遍。日志級別這里也要有講究。不要把業(yè)務(wù)異常的ERROR級別當洪水猛獸在批量任務(wù)中一條數(shù)據(jù)失敗是正常情況級別應(yīng)該用WARN只有整批失敗、服務(wù)不可用、內(nèi)存異常才應(yīng)該用ERROR。不然日志系統(tǒng)里全是ERROR真正嚴重的問題反而不容易區(qū)分。告警這塊我建議按異常類型分組而不是按服務(wù)維度無腦觸發(fā)。BizException可以單獨設(shè)置低頻告警NPE和類轉(zhuǎn)換異常這類程序Bug可以整頁郵件告警Infrastructure異常網(wǎng)絡(luò)超時、數(shù)據(jù)庫連接池打滿要走獨立的高優(yōu)告警通道。6. 團隊規(guī)范與異常處理的長期修養(yǎng)很多人以為異常處理是“語法技巧”但一個項目里異常處理好不好更多取決于團隊有沒有形成一致的規(guī)范。有些原則是靠日積月累沉淀出來的。6.1 異常處理相關(guān)的團隊規(guī)約寧可少吞不可多寫我參與過的幾個項目都定了一些異常相關(guān)的規(guī)約核心大致是禁止捕獲異常后不處理、不輸出、不重新拋出。實現(xiàn)了“處理”就一定要有動作。禁止捕獲Exception后只打e.getMessage()不打堆棧。禁止用異?？刂茦I(yè)務(wù)流程比如用parse異常當校驗分支。禁止在循環(huán)中創(chuàng)建、拋出、捕獲異常來做分支判斷。業(yè)務(wù)異常必須使用統(tǒng)一異常類和統(tǒng)一錯誤碼禁止直接拋new RuntimeException(中文提示)。禁止在finally里return或throw這是代碼review必掛項。這些規(guī)約不是教條每條背后都有一次深刻的線上事故或者繁瑣排查的教訓換來的。6.2 從“會用異常”到“設(shè)計異?！毕裨O(shè)計API一樣設(shè)計你的異常更高一層的異常處理能力是把異常當作API的一部分來設(shè)計。這就意味著異常類型名要說明問題本質(zhì)比如OrderExpiredException而不是BizException 105異常message要有可操作性異常里要能帶上下文參數(shù)調(diào)用方要能從異常中知道下一步該怎么處理。比如一個支付回調(diào)接口拋出的異常類型如果叫PaymentStatusMismatchException里面有orderId、currentStatus、expectedStatus調(diào)用方一看就知道是狀態(tài)流轉(zhuǎn)不對而不是一頭霧水地再去查數(shù)據(jù)庫。好的異常設(shè)計能顯著減少跨部門扯皮尤其在對接第三方系統(tǒng)時異常信息越明確聯(lián)調(diào)效率就越高。6.3 最后再分享一個真正值錢的經(jīng)驗從我個人經(jīng)驗來說排查異常時最容易犯的錯誤是過度依賴異常本身而忽略了正常路徑下的上下文現(xiàn)場。異常只是“結(jié)果先生留下的通知”真正的問題往往發(fā)生在拋異常之前的幾步。比如數(shù)組越界越界只是結(jié)果循環(huán)邊界算錯了才是根因校驗失敗只是結(jié)果數(shù)據(jù)是怎么被污染的才是根因。所以我現(xiàn)在排查異常時會養(yǎng)成一個習慣不僅看異常堆棧還要順著日志往前翻30秒看看異常發(fā)生前這個請求都經(jīng)歷了什么。絕大多數(shù)詭異問題的答案其實都在那段“看似正?！钡娜罩纠?。這也是我把異常處理定義為“長期修養(yǎng)”的原因——它不是幾個語法點而是一整套排查問題、設(shè)計代碼的思維方式。