1. 調(diào)試工具與技巧的底層邏輯重構(gòu)1.1 為什么調(diào)試能力是區(qū)分開(kāi)發(fā)者水平的分水嶺干了這么多年技術(shù)我越來(lái)越覺(jué)得寫代碼這件事本身其實(shí)沒(méi)那么難真正拉開(kāi)差距的是調(diào)試能力。同樣一個(gè)Bug有人十分鐘定位到根因有人折騰兩天還在外圍打轉(zhuǎn)。這中間的差距不是智商問(wèn)題而是方法論和工具鏈的差距。調(diào)試的本質(zhì)是什么我的理解是在有限的信息中用最小的代價(jià)逼近真相。你面對(duì)的是一個(gè)黑盒系統(tǒng)它表現(xiàn)出了異常行為你需要通過(guò)一系列手段逐步縮小可能性空間最終鎖定那個(gè)導(dǎo)致問(wèn)題的變量。這個(gè)過(guò)程跟刑偵破案幾乎一模一樣——現(xiàn)場(chǎng)勘查、線索收集、假設(shè)驗(yàn)證、排除嫌疑、最終定罪。很多人調(diào)試效率低根本原因在于沒(méi)有建立系統(tǒng)化的調(diào)試思維。他們習(xí)慣性地“瞎試”——改一行代碼跑一下不行再改一行。這種方式在簡(jiǎn)單場(chǎng)景下偶爾能碰對(duì)但一旦遇到復(fù)雜系統(tǒng)的問(wèn)題就完全失效了。因?yàn)槟忝鎸?duì)的可能是一個(gè)涉及多線程、網(wǎng)絡(luò)通信、緩存一致性、第三方依賴的復(fù)合型問(wèn)題靠碰運(yùn)氣是不可能解決的。我在帶新人的時(shí)候最常強(qiáng)調(diào)的一點(diǎn)就是先想清楚再動(dòng)手。你每一次修改代碼、每一次加日志、每一次抓包都應(yīng)該是有目的的驗(yàn)證行為而不是隨機(jī)嘗試。這就像醫(yī)生看病先問(wèn)診、再檢查、最后開(kāi)藥而不是一上來(lái)就把所有藥都試一遍。1.2 調(diào)試工具鏈的分層模型調(diào)試工具不是越多越好關(guān)鍵是要分層使用。我習(xí)慣把調(diào)試工具分成四個(gè)層次第一層日志與打印。這是最原始但也最通用的手段。優(yōu)點(diǎn)是零依賴、隨處可用缺點(diǎn)是侵入性強(qiáng)、信息粒度粗、生產(chǎn)環(huán)境往往不方便用。第二層斷點(diǎn)調(diào)試器。包括IDE內(nèi)置的Debugger、瀏覽器DevTools的斷點(diǎn)功能等。優(yōu)點(diǎn)是能實(shí)時(shí)查看變量狀態(tài)、調(diào)用棧、內(nèi)存快照缺點(diǎn)是對(duì)環(huán)境有要求分布式系統(tǒng)或生產(chǎn)環(huán)境很難直接用。第三層鏈路追蹤與監(jiān)控。比如分布式追蹤系統(tǒng)、APM工具、Metrics面板。優(yōu)點(diǎn)是全局視角、非侵入、適合生產(chǎn)環(huán)境缺點(diǎn)是需要提前建設(shè)基礎(chǔ)設(shè)施。第四層專項(xiàng)分析工具。比如內(nèi)存分析器、CPU Profiler、網(wǎng)絡(luò)抓包工具、系統(tǒng)調(diào)用追蹤等。優(yōu)點(diǎn)是能深入到特定領(lǐng)域的最底層缺點(diǎn)是學(xué)習(xí)曲線陡峭需要專業(yè)知識(shí)。注意很多人的問(wèn)題在于只會(huì)在第一層打轉(zhuǎn)遇到復(fù)雜問(wèn)題就束手無(wú)策。你需要根據(jù)問(wèn)題的性質(zhì)主動(dòng)往更高層次走。1.3 調(diào)試思維的三個(gè)核心原則在展開(kāi)具體工具之前我想先把調(diào)試思維的三個(gè)核心原則講清楚因?yàn)楣ぞ咧皇鞘侄嗡季S才是根本。原則一二分法定位。這是最高效的定位策略。不管是代碼邏輯問(wèn)題還是性能問(wèn)題你都要學(xué)會(huì)快速縮小范圍。比如一個(gè)接口返回異常你先確認(rèn)是前端問(wèn)題還是后端問(wèn)題確認(rèn)是后端之后再確認(rèn)是業(yè)務(wù)邏輯問(wèn)題還是數(shù)據(jù)問(wèn)題確認(rèn)是數(shù)據(jù)問(wèn)題之后再確認(rèn)是寫入問(wèn)題還是讀取問(wèn)題。每一步都砍掉一半的可能性空間很快就能逼近根因。原則二最小復(fù)現(xiàn)。能穩(wěn)定復(fù)現(xiàn)的問(wèn)題才是好問(wèn)題。如果你面對(duì)的是一個(gè)偶發(fā)問(wèn)題第一優(yōu)先級(jí)不是去猜原因而是想辦法提高復(fù)現(xiàn)頻率。我通常會(huì)嘗試增加并發(fā)量、縮短觸發(fā)間隔、調(diào)整時(shí)序參數(shù)、模擬特定環(huán)境條件。一旦能穩(wěn)定復(fù)現(xiàn)問(wèn)題就解決了一半。原則三假設(shè)驅(qū)動(dòng)。每次調(diào)試都應(yīng)該基于一個(gè)明確的假設(shè)。比如“我懷疑是緩存沒(méi)失效導(dǎo)致讀到舊數(shù)據(jù)”然后你去驗(yàn)證這個(gè)假設(shè)——清掉緩存再試一次如果問(wèn)題消失假設(shè)成立如果問(wèn)題依舊假設(shè)推翻換下一個(gè)。這種“假設(shè)-驗(yàn)證”的循環(huán)比漫無(wú)目的地翻代碼高效得多。2. 日志與打印最樸素但最有效的調(diào)試手段2.1 日志級(jí)別與輸出策略的合理設(shè)計(jì)日志這東西看起來(lái)簡(jiǎn)單但用好了真不容易。我見(jiàn)過(guò)太多項(xiàng)目日志要么打得太多——滿屏都是無(wú)用信息關(guān)鍵線索淹沒(méi)在里面要么打得太少——出了問(wèn)題什么都查不到。合理的日志策略應(yīng)該是分級(jí)分類的。分級(jí)就是常見(jiàn)的DEBUG、INFO、WARN、ERROR但關(guān)鍵是要明確每個(gè)級(jí)別的使用場(chǎng)景級(jí)別使用場(chǎng)景生產(chǎn)環(huán)境是否開(kāi)啟典型示例DEBUG開(kāi)發(fā)調(diào)試細(xì)節(jié)如變量值、循環(huán)次數(shù)否“當(dāng)前處理第3條記錄IDxxx”INFO關(guān)鍵業(yè)務(wù)流程節(jié)點(diǎn)是“訂單創(chuàng)建成功訂單號(hào)xxx”WARN可恢復(fù)的異常情況是“緩存未命中回源查詢數(shù)據(jù)庫(kù)”ERROR需要人工介入的異常是“數(shù)據(jù)庫(kù)連接失敗重試3次后放棄”分類則是按業(yè)務(wù)模塊或功能維度來(lái)組織日志比如訂單模塊、支付模塊、用戶模塊各自有獨(dú)立的Logger。這樣出問(wèn)題的時(shí)候你可以快速過(guò)濾出相關(guān)模塊的日志而不是在幾萬(wàn)行日志里大海撈針。我個(gè)人的經(jīng)驗(yàn)是在關(guān)鍵路徑的入口和出口各打一條INFO日志記錄輸入?yún)?shù)和輸出結(jié)果。這樣即使出了問(wèn)題你至少知道是哪個(gè)環(huán)節(jié)掛了。然后在可疑的中間步驟加DEBUG日志定位到具體行之后再關(guān)掉。2.2 結(jié)構(gòu)化日志與上下文傳遞傳統(tǒng)的文本日志有個(gè)致命問(wèn)題難以檢索和關(guān)聯(lián)。比如你想查某個(gè)用戶的所有操作記錄如果用文本日志你得grep用戶名但用戶名可能出現(xiàn)在各種不同的日志格式里很容易漏掉或誤匹配。結(jié)構(gòu)化日志通常用JSON格式解決了這個(gè)問(wèn)題。每條日志都是一個(gè)JSON對(duì)象包含時(shí)間戳、級(jí)別、模塊、消息、以及任意自定義字段。這樣你可以用日志系統(tǒng)如ELK、Loki等做精確查詢和聚合分析。{ timestamp: 2025-01-15T10:23:45.123Z, level: ERROR, module: payment, message: 支付回調(diào)驗(yàn)簽失敗, orderId: ORD-20250115-001, userId: U-12345, traceId: abc-def-ghi-123, errorCode: SIGN_INVALID }這里特別要提的是traceId。在分布式系統(tǒng)中一個(gè)請(qǐng)求可能經(jīng)過(guò)多個(gè)服務(wù)每個(gè)服務(wù)都打自己的日志。如果沒(méi)有一個(gè)統(tǒng)一的traceId串聯(lián)你根本沒(méi)法把一次請(qǐng)求的完整鏈路拼出來(lái)。我通常的做法是在請(qǐng)求入口生成一個(gè)唯一的traceId然后通過(guò)上下文Context在整個(gè)調(diào)用鏈中傳遞每個(gè)服務(wù)的日志都帶上這個(gè)traceId。這樣排查問(wèn)題時(shí)只需要用traceId搜一下整條鏈路的日志就全出來(lái)了。實(shí)操心得traceId的生成可以用UUID也可以用雪花算法。關(guān)鍵是保證全局唯一且有序有序的話方便按時(shí)間排序。另外traceId一定要在跨進(jìn)程通信時(shí)透?jìng)鞅热鏗TTP Header、消息隊(duì)列的Message Header里都要帶上。2.3 日志的坑與避坑指南日志這塊我踩過(guò)的坑不少挑幾個(gè)典型的說(shuō)說(shuō)。坑一日志里打印敏感信息。這個(gè)不用多說(shuō)密碼、密鑰、身份證號(hào)這些東西絕對(duì)不能進(jìn)日志。我見(jiàn)過(guò)有項(xiàng)目把用戶的完整請(qǐng)求體打進(jìn)日志里面包含密碼明文這是嚴(yán)重的安全事故。坑二大對(duì)象toString導(dǎo)致性能問(wèn)題。有些開(kāi)發(fā)者習(xí)慣把整個(gè)對(duì)象toString后打進(jìn)日志如果這個(gè)對(duì)象很大比如包含幾千條記錄的列表toString本身就很耗時(shí)而且會(huì)產(chǎn)生大量日志拖慢系統(tǒng)。正確的做法是只打印關(guān)鍵字段。坑三日志同步寫導(dǎo)致阻塞。在高并發(fā)場(chǎng)景下如果日志是同步寫磁盤的磁盤IO可能成為瓶頸。解決方案是用異步Appender把日志先寫入內(nèi)存隊(duì)列由后臺(tái)線程批量刷盤。但要注意隊(duì)列滿了之后的降級(jí)策略——是丟棄還是阻塞需要根據(jù)業(yè)務(wù)場(chǎng)景權(quán)衡。坑四日志文件沒(méi)有輪轉(zhuǎn)。這個(gè)屬于運(yùn)維層面的問(wèn)題但開(kāi)發(fā)也要關(guān)注。如果日志文件不輪轉(zhuǎn)磁盤很快就會(huì)被寫滿然后整個(gè)服務(wù)掛掉。通常用Logrotate或日志框架自帶的RollingPolicy來(lái)解決。3. 斷點(diǎn)調(diào)試器交互式排查的利器3.1 斷點(diǎn)類型與使用場(chǎng)景很多人用斷點(diǎn)就只會(huì)打一個(gè)行斷點(diǎn)然后一步步Step Over。其實(shí)斷點(diǎn)的種類遠(yuǎn)不止這一種不同場(chǎng)景下用不同類型的斷點(diǎn)效率天差地別。行斷點(diǎn)是最基礎(chǔ)的在指定行暫停執(zhí)行。適合精確定位到某一行代碼的邏輯問(wèn)題。條件斷點(diǎn)是行斷點(diǎn)的增強(qiáng)版只有滿足特定條件時(shí)才暫停。比如你在一個(gè)循環(huán)里只想在i100的時(shí)候停下來(lái)就可以用條件斷點(diǎn)。這個(gè)在調(diào)試大數(shù)據(jù)量循環(huán)時(shí)特別有用否則你要手動(dòng)Continue 99次。異常斷點(diǎn)是在拋出指定異常時(shí)暫停。這個(gè)在排查“不知道為什么拋異?！钡膱?chǎng)景下非常高效。你可以設(shè)置只在特定異常類型拋出時(shí)暫停然后查看當(dāng)時(shí)的調(diào)用棧和變量狀態(tài)。方法斷點(diǎn)是在進(jìn)入或退出某個(gè)方法時(shí)暫停。適合你想跟蹤某個(gè)方法的調(diào)用情況但不想在方法內(nèi)部逐行調(diào)試的場(chǎng)景。字段斷點(diǎn)也叫Watchpoint是在某個(gè)字段被讀寫時(shí)暫停。這個(gè)在排查“這個(gè)值什么時(shí)候被改掉的”這類問(wèn)題時(shí)簡(jiǎn)直是神器。比如你發(fā)現(xiàn)一個(gè)對(duì)象的某個(gè)字段莫名其妙變成了null就可以在這個(gè)字段上打一個(gè)寫斷點(diǎn)誰(shuí)改的、什么時(shí)候改的一目了然。斷點(diǎn)類型適用場(chǎng)景典型問(wèn)題行斷點(diǎn)精確定位某行邏輯變量值不符合預(yù)期條件斷點(diǎn)循環(huán)中特定條件觸發(fā)第N次循環(huán)時(shí)結(jié)果異常異常斷點(diǎn)異常拋出點(diǎn)不明不知道哪里拋的異常方法斷點(diǎn)跟蹤方法調(diào)用方法被誰(shuí)調(diào)用了字段斷點(diǎn)字段值被意外修改值什么時(shí)候變的3.2 遠(yuǎn)程調(diào)試的配置與實(shí)戰(zhàn)本地調(diào)試很簡(jiǎn)單但很多時(shí)候問(wèn)題只出現(xiàn)在測(cè)試環(huán)境或預(yù)發(fā)環(huán)境你沒(méi)法在本地復(fù)現(xiàn)。這時(shí)候就需要遠(yuǎn)程調(diào)試。以Java為例遠(yuǎn)程調(diào)試的原理是通過(guò)JDWPJava Debug Wire Protocol協(xié)議讓本地的IDE連接到遠(yuǎn)程JVM的調(diào)試端口。具體操作是在啟動(dòng)參數(shù)里加上java -agentlib:jdwptransportdt_socket,servery,suspendn,address*:5005 -jar app.jar然后在IDE里配置一個(gè)Remote JVM Debug填入遠(yuǎn)程IP和端口就可以像本地調(diào)試一樣打斷點(diǎn)了。但遠(yuǎn)程調(diào)試有幾個(gè)必須注意的點(diǎn)第一suspend參數(shù)。如果設(shè)為yJVM啟動(dòng)時(shí)會(huì)暫停等待調(diào)試器連接設(shè)為n則正常啟動(dòng)調(diào)試器隨時(shí)可以連上。生產(chǎn)環(huán)境絕對(duì)不要開(kāi)遠(yuǎn)程調(diào)試測(cè)試環(huán)境建議設(shè)為n。第二網(wǎng)絡(luò)延遲。遠(yuǎn)程調(diào)試時(shí)每次斷點(diǎn)暫停、查看變量都需要網(wǎng)絡(luò)往返體驗(yàn)比本地差很多。所以遠(yuǎn)程調(diào)試更適合“精準(zhǔn)打擊”——你已經(jīng)大致知道問(wèn)題在哪只需要確認(rèn)一下變量值而不是漫無(wú)目的地單步執(zhí)行。第三超時(shí)問(wèn)題。如果斷點(diǎn)暫停時(shí)間過(guò)長(zhǎng)可能導(dǎo)致客戶端請(qǐng)求超時(shí)、心跳斷開(kāi)等連鎖反應(yīng)。調(diào)試完成后一定要記得斷開(kāi)連接并移除調(diào)試參數(shù)。注意有些團(tuán)隊(duì)會(huì)在測(cè)試環(huán)境的啟動(dòng)腳本里默認(rèn)開(kāi)啟遠(yuǎn)程調(diào)試端口這其實(shí)有安全風(fēng)險(xiǎn)。建議只在需要時(shí)臨時(shí)開(kāi)啟用完就關(guān)。3.3 斷點(diǎn)調(diào)試的高級(jí)技巧斷點(diǎn)調(diào)試有一些技巧掌握了能大幅提升效率。技巧一修改變量值。在斷點(diǎn)暫停時(shí)很多IDE允許你直接修改變量的值然后繼續(xù)執(zhí)行。這個(gè)在驗(yàn)證假設(shè)時(shí)非常有用——比如你懷疑某個(gè)變量為null導(dǎo)致空指針可以手動(dòng)把它改成非null看看問(wèn)題是否消失。技巧二表達(dá)式求值。斷點(diǎn)暫停時(shí)你可以執(zhí)行任意表達(dá)式比如調(diào)用某個(gè)方法、計(jì)算某個(gè)值。這個(gè)在你想驗(yàn)證某個(gè)邏輯但沒(méi)有寫在代碼里時(shí)特別方便。技巧三多線程調(diào)試。多線程場(chǎng)景下斷點(diǎn)默認(rèn)會(huì)暫停所有線程但你可以配置為只暫停當(dāng)前線程。另外IDE通常提供線程面板可以看到所有線程的狀態(tài)和調(diào)用棧對(duì)排查死鎖、線程饑餓等問(wèn)題很有幫助。技巧四Drop Frame。這個(gè)功能允許你回退到上一個(gè)方法調(diào)用的起點(diǎn)重新執(zhí)行。相當(dāng)于“時(shí)光倒流”在你不小心Step Over過(guò)頭了的時(shí)候特別有用。但要注意Drop Frame只能回退棧幀不能撤銷已經(jīng)產(chǎn)生的副作用比如已經(jīng)寫入數(shù)據(jù)庫(kù)的數(shù)據(jù)。4. 鏈路追蹤與生產(chǎn)環(huán)境調(diào)試4.1 分布式追蹤的核心概念單體應(yīng)用時(shí)代一個(gè)請(qǐng)求的所有處理邏輯都在一個(gè)進(jìn)程里出了問(wèn)題看日志就夠了。但在微服務(wù)架構(gòu)下一個(gè)請(qǐng)求可能經(jīng)過(guò)網(wǎng)關(guān)、認(rèn)證服務(wù)、業(yè)務(wù)服務(wù)、緩存、數(shù)據(jù)庫(kù)、消息隊(duì)列等十幾個(gè)組件任何一個(gè)環(huán)節(jié)出問(wèn)題都可能導(dǎo)致整體異常。分布式追蹤的核心思想是給每個(gè)請(qǐng)求分配一個(gè)全局唯一的Trace ID并在每個(gè)處理環(huán)節(jié)記錄Span跨度信息。一個(gè)Trace由多個(gè)Span組成每個(gè)Span代表一個(gè)處理單元比如一次RPC調(diào)用、一次數(shù)據(jù)庫(kù)查詢包含開(kāi)始時(shí)間、結(jié)束時(shí)間、耗時(shí)、狀態(tài)等元信息。這樣你就能看到一個(gè)請(qǐng)求的完整調(diào)用鏈路Trace: abc-123 ├── Span: API Gateway (0ms - 5ms) ├── Span: Auth Service (5ms - 15ms) ├── Span: Order Service (15ms - 120ms) │ ├── Span: Redis Query (20ms - 25ms) │ ├── Span: MySQL Query (30ms - 80ms) │ └── Span: MQ Publish (85ms - 95ms) └── Span: Response (120ms - 125ms)一眼就能看出瓶頸在MySQL查詢上耗時(shí)50ms。如果沒(méi)有鏈路追蹤你只能看到總耗時(shí)120ms根本不知道時(shí)間花在哪了。4.2 生產(chǎn)環(huán)境調(diào)試的安全邊界生產(chǎn)環(huán)境調(diào)試是個(gè)敏感話題。一方面很多問(wèn)題只在生產(chǎn)環(huán)境出現(xiàn)你不得不在生產(chǎn)環(huán)境排查另一方面生產(chǎn)環(huán)境直接面向用戶任何操作都可能影響業(yè)務(wù)。我的原則是只讀操作可以做寫操作必須極度謹(jǐn)慎。安全的操作包括查看日志、查看監(jiān)控面板、查看鏈路追蹤、查看線程棧jstack、查看內(nèi)存快照heap dump、查看網(wǎng)絡(luò)連接狀態(tài)netstat。這些操作基本不影響業(yè)務(wù)運(yùn)行。需要謹(jǐn)慎的操作包括動(dòng)態(tài)調(diào)整日志級(jí)別可能產(chǎn)生大量日志影響性能、動(dòng)態(tài)修改配置可能觸發(fā)意外行為、遠(yuǎn)程調(diào)試會(huì)暫停JVM。這些操作一定要在低峰期進(jìn)行并且提前通知相關(guān)方。絕對(duì)禁止的操作包括在生產(chǎn)環(huán)境直接修改代碼、重啟服務(wù)除非是緊急故障處理、執(zhí)行未經(jīng)審核的SQL。實(shí)操心得我通常會(huì)在生產(chǎn)環(huán)境預(yù)留一個(gè)“調(diào)試開(kāi)關(guān)”通過(guò)配置中心動(dòng)態(tài)開(kāi)啟DEBUG日志或特定埋點(diǎn)。出問(wèn)題時(shí)打開(kāi)開(kāi)關(guān)收集信息收集完立即關(guān)閉。這樣既不影響日常運(yùn)行又能在需要時(shí)獲取足夠的信息。4.3 從監(jiān)控指標(biāo)反推問(wèn)題根因鏈路追蹤解決的是“單個(gè)請(qǐng)求為什么慢”的問(wèn)題而監(jiān)控指標(biāo)解決的是“整體系統(tǒng)健康狀況”的問(wèn)題。兩者配合使用效果最好。常用的監(jiān)控指標(biāo)包括RED指標(biāo)Rate請(qǐng)求速率、Errors錯(cuò)誤率、Duration響應(yīng)時(shí)間。這是服務(wù)級(jí)別的黃金指標(biāo)能快速判斷服務(wù)是否正常。USE指標(biāo)Utilization使用率、Saturation飽和度、Errors錯(cuò)誤數(shù)。這是資源級(jí)別的指標(biāo)適用于CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等。業(yè)務(wù)指標(biāo)訂單量、支付成功率、用戶活躍度等。這些指標(biāo)能反映業(yè)務(wù)層面的異常。排查問(wèn)題時(shí)我通常先看RED指標(biāo)確認(rèn)哪個(gè)服務(wù)異常然后看USE指標(biāo)確認(rèn)是不是資源瓶頸最后用鏈路追蹤定位到具體的慢操作。這套組合拳下來(lái)大部分問(wèn)題都能快速定位。5. 專項(xiàng)分析工具與進(jìn)階技巧5.1 內(nèi)存與CPU問(wèn)題排查內(nèi)存泄漏和CPU飆高是兩類最讓人頭疼的問(wèn)題因?yàn)樗鼈兺皇沁壿嬪e(cuò)誤而是資源管理問(wèn)題靠看代碼很難發(fā)現(xiàn)。內(nèi)存問(wèn)題排查的常用工具是堆轉(zhuǎn)儲(chǔ)Heap Dump和內(nèi)存分析器。當(dāng)發(fā)現(xiàn)內(nèi)存持續(xù)增長(zhǎng)時(shí)先抓一份堆轉(zhuǎn)儲(chǔ)文件jmap -dump:formatb,fileheap.hprof pid然后用MAT或VisualVM等工具打開(kāi)查看對(duì)象占用情況。重點(diǎn)看兩個(gè)東西一是占用內(nèi)存最多的對(duì)象類型二是對(duì)象之間的引用鏈。通常能找到某個(gè)集合類不斷增長(zhǎng)但從不清理或者某個(gè)緩存沒(méi)有設(shè)置過(guò)期時(shí)間。CPU問(wèn)題排查的常用工具是線程棧和CPU Profiler。當(dāng)CPU飆高時(shí)先連續(xù)抓幾份線程棧jstack pid thread1.txt sleep 5 jstack pid thread2.txt然后對(duì)比幾份線程?？茨男┚€程一直處于RUNNABLE狀態(tài)且調(diào)用棧相同。那個(gè)反復(fù)出現(xiàn)的調(diào)用棧就是熱點(diǎn)代碼。常見(jiàn)的原因包括死循環(huán)、正則表達(dá)式回溯、頻繁GC、鎖競(jìng)爭(zhēng)等。問(wèn)題類型首選工具關(guān)鍵指標(biāo)常見(jiàn)根因內(nèi)存泄漏Heap Dump MAT對(duì)象增長(zhǎng)趨勢(shì)集合未清理、緩存無(wú)過(guò)期CPU飆高jstack Profiler線程狀態(tài)分布死循環(huán)、正則回溯、GC線程死鎖jstack死鎖檢測(cè)鎖順序不一致磁盤IO高iostat lsofIO等待時(shí)間日志同步寫、大文件讀寫5.2 網(wǎng)絡(luò)抓包與協(xié)議分析有些問(wèn)題出在網(wǎng)絡(luò)層面比如請(qǐng)求超時(shí)、連接被重置、數(shù)據(jù)包丟失等。這時(shí)候就需要抓包分析。常用的抓包工具是tcpdump和Wireshark。tcpdump用于在服務(wù)器上抓包Wireshark用于圖形化分析。tcpdump -i eth0 -w capture.pcap port 8080抓包時(shí)要注意幾點(diǎn)一是過(guò)濾條件要精確否則抓出來(lái)的包太大沒(méi)法分析二是抓包時(shí)間要覆蓋問(wèn)題發(fā)生的時(shí)間段三是注意權(quán)限tcpdump通常需要root權(quán)限。抓到包之后用Wireshark打開(kāi)重點(diǎn)關(guān)注TCP三次握手是否正常、是否有重傳、是否有RST包、TLS握手是否成功、HTTP請(qǐng)求和響應(yīng)是否完整。這些信息能幫你判斷問(wèn)題出在網(wǎng)絡(luò)層、傳輸層還是應(yīng)用層。5.3 動(dòng)態(tài)追蹤技術(shù)動(dòng)態(tài)追蹤是一種在生產(chǎn)環(huán)境低開(kāi)銷排查問(wèn)題的高級(jí)技術(shù)。它的核心思想是在不修改代碼、不重啟服務(wù)的前提下動(dòng)態(tài)地在指定位置插入探針收集運(yùn)行時(shí)信息。常見(jiàn)的動(dòng)態(tài)追蹤工具包括DTrace、SystemTap、eBPF等。以eBPF為例你可以用它追蹤系統(tǒng)調(diào)用、內(nèi)核函數(shù)、用戶態(tài)函數(shù)而且性能開(kāi)銷極低。動(dòng)態(tài)追蹤適合排查那些“偶發(fā)、難以復(fù)現(xiàn)、不想加日志”的問(wèn)題。比如你想知道某個(gè)系統(tǒng)調(diào)用為什么偶爾返回錯(cuò)誤就可以用eBPF掛一個(gè)探針只在錯(cuò)誤發(fā)生時(shí)輸出上下文信息。不過(guò)動(dòng)態(tài)追蹤的學(xué)習(xí)曲線比較陡需要了解操作系統(tǒng)內(nèi)核和編程語(yǔ)言運(yùn)行時(shí)的知識(shí)。建議先從簡(jiǎn)單的場(chǎng)景入手比如追蹤文件IO、網(wǎng)絡(luò)連接逐步深入。6. 常見(jiàn)調(diào)試場(chǎng)景與速查手冊(cè)6.1 接口超時(shí)問(wèn)題排查思路接口超時(shí)是最常見(jiàn)的問(wèn)題之一。排查思路可以總結(jié)為“從外到內(nèi)逐層剝離”。第一步確認(rèn)超時(shí)發(fā)生的具體環(huán)節(jié)。是客戶端到網(wǎng)關(guān)超時(shí)還是網(wǎng)關(guān)到服務(wù)超時(shí)還是服務(wù)內(nèi)部處理超時(shí)這可以通過(guò)鏈路追蹤或日志時(shí)間戳來(lái)判斷。第二步如果是服務(wù)內(nèi)部處理超時(shí)看是CPU密集型還是IO密集型。CPU密集型通常是計(jì)算邏輯有問(wèn)題IO密集型通常是數(shù)據(jù)庫(kù)查詢、RPC調(diào)用、文件讀寫慢。第三步針對(duì)IO密集型進(jìn)一步確認(rèn)是哪個(gè)依賴慢。數(shù)據(jù)庫(kù)慢可能是索引缺失、鎖等待、數(shù)據(jù)量過(guò)大RPC慢可能是下游服務(wù)本身慢或網(wǎng)絡(luò)延遲文件讀寫慢可能是磁盤性能問(wèn)題。第四步針對(duì)具體原因采取優(yōu)化措施。加索引、加緩存、異步化、限流降級(jí)等。6.2 內(nèi)存泄漏快速定位方法內(nèi)存泄漏的排查有一套標(biāo)準(zhǔn)流程確認(rèn)是否真的泄漏?？碐C日志如果Full GC后老年代內(nèi)存仍然持續(xù)增長(zhǎng)基本可以確認(rèn)泄漏。抓取堆轉(zhuǎn)儲(chǔ)。在內(nèi)存增長(zhǎng)到接近上限時(shí)抓取這樣泄漏對(duì)象最明顯。用MAT分析支配樹(shù)?？茨男?duì)象占用了最多內(nèi)存以及它們的引用鏈。找到泄漏根因。通常是某個(gè)靜態(tài)集合不斷添加元素、ThreadLocal未清理、監(jiān)聽(tīng)器未注銷等。修復(fù)并驗(yàn)證。修復(fù)后持續(xù)觀察內(nèi)存曲線確認(rèn)不再增長(zhǎng)。避坑技巧抓堆轉(zhuǎn)儲(chǔ)時(shí)會(huì)觸發(fā)Full GC默認(rèn)行為可能導(dǎo)致服務(wù)暫停幾秒。如果服務(wù)對(duì)延遲敏感可以加上-all參數(shù)只抓存活對(duì)象或者用jcmd的GC.heap_dump命令。6.3 并發(fā)問(wèn)題的調(diào)試策略并發(fā)問(wèn)題是最難調(diào)試的一類問(wèn)題因?yàn)樗鼈兺豢煞€(wěn)定復(fù)現(xiàn)而且涉及時(shí)序和狀態(tài)。我的策略是先復(fù)現(xiàn)再分析最后驗(yàn)證。復(fù)現(xiàn)階段嘗試提高并發(fā)量、調(diào)整線程池大小、增加隨機(jī)延遲來(lái)放大問(wèn)題。有時(shí)候加一行Thread.sleep(1)就能讓隱藏的競(jìng)態(tài)條件暴露出來(lái)。分析階段用線程棧、鎖信息、內(nèi)存屏障等工具來(lái)理解線程之間的交互。重點(diǎn)關(guān)注共享變量的讀寫、鎖的獲取釋放順序、volatile和synchronized的使用。驗(yàn)證階段修復(fù)后要用壓力測(cè)試反復(fù)驗(yàn)證確保問(wèn)題不再出現(xiàn)。并發(fā)問(wèn)題的修復(fù)往往需要多次迭代不要指望一次就能搞定。并發(fā)問(wèn)題類型典型表現(xiàn)排查工具解決思路競(jìng)態(tài)條件結(jié)果不一致線程棧、日志加鎖、CAS死鎖線程卡死jstack統(tǒng)一鎖順序活鎖線程空轉(zhuǎn)線程棧退避策略內(nèi)存可見(jiàn)性讀到舊值內(nèi)存分析volatile、屏障7. 調(diào)試效率的持續(xù)提升7.1 建立個(gè)人調(diào)試知識(shí)庫(kù)調(diào)試能力不是一蹴而就的需要持續(xù)積累。我建議每個(gè)人都建立自己的調(diào)試知識(shí)庫(kù)記錄每次排查問(wèn)題的過(guò)程、用到的工具、最終的根因和解決方案。這個(gè)知識(shí)庫(kù)不需要很正式用筆記軟件就行。關(guān)鍵是要記錄“癥狀-工具-根因-解決”這條鏈路。下次遇到類似癥狀時(shí)可以直接翻出來(lái)參考省去大量摸索時(shí)間。我自己的知識(shí)庫(kù)已經(jīng)積累了幾百條記錄覆蓋了各種奇葩問(wèn)題。比如“MySQL連接池耗盡導(dǎo)致接口全部超時(shí)”、“Redis大key導(dǎo)致主從同步延遲”、“線程池隊(duì)列滿導(dǎo)致任務(wù)被拒絕”等等。每次翻到類似的記錄都能快速定位方向。7.2 工具鏈的自動(dòng)化與集成手動(dòng)調(diào)試效率有限把常用調(diào)試操作自動(dòng)化能省不少時(shí)間。比如寫一個(gè)腳本一鍵抓取線程棧、堆轉(zhuǎn)儲(chǔ)、GC日志、網(wǎng)絡(luò)連接狀態(tài)打包成一個(gè)診斷包。在CI/CD流程里集成靜態(tài)分析工具提前發(fā)現(xiàn)潛在的資源泄漏、并發(fā)問(wèn)題。配置告警規(guī)則當(dāng)關(guān)鍵指標(biāo)異常時(shí)自動(dòng)觸發(fā)診斷腳本把現(xiàn)場(chǎng)信息保存下來(lái)。這些自動(dòng)化手段能讓你在問(wèn)題發(fā)生時(shí)快速拿到第一手資料而不是手忙腳亂地一個(gè)個(gè)登錄服務(wù)器執(zhí)行命令。7.3 從調(diào)試到預(yù)防的思維轉(zhuǎn)變最后我想說(shuō)的是調(diào)試的最高境界是不需要調(diào)試。也就是說(shuō)通過(guò)良好的設(shè)計(jì)、充分的測(cè)試、完善的監(jiān)控把問(wèn)題消滅在發(fā)生之前。具體來(lái)說(shuō)寫代碼時(shí)考慮邊界條件和異常路徑做設(shè)計(jì)時(shí)考慮容量和降級(jí)上線前做充分的壓測(cè)和混沌測(cè)試上線后配置完善的監(jiān)控和告警。這些工作做到位了需要調(diào)試的場(chǎng)景自然就少了。當(dāng)然完全不調(diào)試是不可能的。但每次調(diào)試完之后都應(yīng)該問(wèn)自己一個(gè)問(wèn)題這個(gè)問(wèn)題能不能通過(guò)改進(jìn)流程或工具來(lái)避免再次發(fā)生如果能就去改進(jìn)。這樣你的系統(tǒng)會(huì)越來(lái)越健壯調(diào)試的負(fù)擔(dān)也會(huì)越來(lái)越輕。我在實(shí)際工作中最大的體會(huì)是調(diào)試工具和技巧固然重要但更重要的是調(diào)試的心態(tài)。遇到問(wèn)題不要慌不要瞎猜按照“觀察-假設(shè)-驗(yàn)證-結(jié)論”的循環(huán)一步步來(lái)。大部分問(wèn)題都是可以被解決的只是需要耐心和方法。