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