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