排查 Java 服務(wù)的性能問題命令行里常見的套路是先top看一眼負(fù)載再用jstack拉線程棧條件允許的話上jmap或者jcmd再看堆。這套流程能回答“哪里慢”但是常常回答不了“為什么慢”。我上次在一臺(tái)只剩 SSH 的白盒服務(wù)器上排查接口延遲時(shí)發(fā)現(xiàn)線程棧反復(fù)提示某個(gè)方法在忙但光靠棧信息完全看不出是入?yún)⒌膯栴}還是循環(huán)的邏輯問題。這時(shí)候需要的不是采樣工具而是一個(gè)能把程序暫停下來、讓我把當(dāng)前變量和調(diào)用關(guān)系看得明明白白的調(diào)試器。JDB 就是 JDK 自帶的那把“手術(shù)刀”它沒有圖形界面、也不用裝插件專治這種需要現(xiàn)場取證的場景。這篇文章就把我在真實(shí)排查中摸熟的 JDB 用法、踩坑記錄和與其它性能工具配合的思路整理出來。1. 為什么說 JDB 是性能排查鏈路里最被低估的調(diào)試工具1.1 從定位到取證JDB 和性能工具的關(guān)系大多數(shù)人對(duì) JDB 的第一印象是“命令行調(diào)試器”和性能分析沒什么關(guān)系。這個(gè)印象不準(zhǔn)確。性能工具可以分為兩層第一層負(fù)責(zé)定位例如用 JFR 或 async-profiler 做 CPU 采樣用jstat觀察 GC 節(jié)奏用jstack抓線程卡點(diǎn)第二層負(fù)責(zé)取證也就是當(dāng)你知道問題出在某個(gè)方法、某個(gè)對(duì)象或者某個(gè)線程狀態(tài)時(shí)需要停下來把現(xiàn)場翻個(gè)底朝天。JDB 屬于第二層。它本質(zhì)上是 JDK 官方提供的 Java 調(diào)試工具底層走的是 JPDA 體系通過 JVM 的調(diào)試接口獲取運(yùn)行信息。IDE 里的斷點(diǎn)、單步、變量檢查本質(zhì)上和它是同一套機(jī)制只不過 IDE 把命令封裝成了圖形按鈕。換句話說你日常在 IDEA 里做的那套調(diào)試動(dòng)作JDB 全部能做只是在命令行里完成?？粗匦阅艿娜顺７敢粋€(gè)誤區(qū)覺得調(diào)試器只能在開發(fā)環(huán)境用。實(shí)際上在做性能分析的后期尤其是問題已經(jīng)縮到某個(gè)類、某個(gè)方法甚至某一行時(shí)JDB 的價(jià)值非常大。比如一個(gè)接口響應(yīng)突然變慢jstack只能看到線程停留在某處但你不知道它手里拿到的List到底有多大不知道某個(gè)字段是不是已經(jīng)變成null不知道循環(huán)條件為什么一直沒有退出。這些信息只有把程序暫停下來才能確認(rèn)而 JDB 就是干這個(gè)的。1.2 哪些場景該用它哪些場景不該用它先說適合的場景。目標(biāo)機(jī)器是無桌面環(huán)境的 Linux、容器或云主機(jī)沒法開 IDE問題屬于偶發(fā)需要等到某個(gè)條件滿足時(shí)立刻觀察現(xiàn)場程序啟動(dòng)階段就有異常需要從第一條指令開始調(diào)試或者團(tuán)隊(duì)在做自動(dòng)化故障演練希望用腳本把“設(shè)置斷點(diǎn)、觸發(fā)、抓棧、退出”變成一條命令。這些場景下 JDB 幾乎是零成本的選擇因?yàn)?JDK 裝好之后它就躺在bin目錄里。不太適合的場景也很明確需要統(tǒng)計(jì)熱點(diǎn)方法耗時(shí)、需要生成火焰圖、需要大面積采集樣本時(shí)JDB 不是干這個(gè)的。它會(huì)讓目標(biāo)線程停下來逐幀檢查狀態(tài)這種“顯微鏡”式的操作不適合做全局掃描。原因在于 JDB 啟動(dòng)后會(huì)啟用調(diào)試基礎(chǔ)設(shè)施被附加的 JVM 內(nèi)部會(huì)有額外事件處理的開銷而且斷點(diǎn)如果設(shè)置不當(dāng)會(huì)讓本來應(yīng)該在熱路徑上的代碼被強(qiáng)制掛起。所以正確的打開方式是先用采樣工具畫出輪廓再用 JDB 做定點(diǎn)解剖。2. 先把 JDB 跑起來兩種啟動(dòng)方式與常用會(huì)話配置2.1 直接啟動(dòng)目標(biāo) Java 程序第一種方式是讓 JDB 直接啟動(dòng)目標(biāo) Java 類適合調(diào)試本地可復(fù)現(xiàn)的問題。命令格式很簡單jdb -classpath target/classes com.example.OrderService執(zhí)行后會(huì)進(jìn)入jdb提示符但此時(shí)目標(biāo)程序還沒有真正跑起來。新手最容易在這里踩坑直接輸入run程序瞬間跑完還沒反應(yīng)過來調(diào)試就結(jié)束了。正確的做法是先設(shè)置好斷點(diǎn)再發(fā)起運(yùn)行。例如 stop at com.example.OrderService:126 runrun之后 JDB 才會(huì)拉起目標(biāo) JVM。如果程序一開始就命中斷點(diǎn)會(huì)進(jìn)入暫停狀態(tài)這時(shí)候可以做棧和變量檢查。如果程序能一路跑完最后 JDB 會(huì)提示目標(biāo)進(jìn)程退出整個(gè)調(diào)試會(huì)話當(dāng)然也就結(jié)束了。直接啟動(dòng)時(shí)還可以帶參數(shù)例如run arg1 arg2會(huì)把參數(shù)傳給目標(biāo)程序。對(duì)于有多個(gè) classpath 的項(xiàng)目用-classpath指定即可。如果你有多個(gè)依賴 jar建議把它們都列在啟動(dòng)參數(shù)里否則 JDB 在解析某個(gè)斷點(diǎn)類時(shí)會(huì)提示找不到類。2.2 掛到運(yùn)行中的 JVMJDWP 參數(shù)是關(guān)鍵遠(yuǎn)程或線上問題的調(diào)試更多用的是第二種方式目標(biāo) JVM 已經(jīng)跑著JDB 從外部附加進(jìn)去。這里有一個(gè)前置步驟容易被忽略目標(biāo) JVM 必須要以調(diào)試模式啟動(dòng)也就是帶上 JDWP 代理參數(shù)。我常用的啟動(dòng)參數(shù)是這樣的java -agentlib:jdwptransportdt_socket,servery,suspendn,address127.0.0.1:8787 -jar order-service.jar每個(gè)參數(shù)的含義都比較固定我按自己的習(xí)慣解釋一下。參數(shù)作用transportdt_socket指定調(diào)試通信走 Socket 協(xié)議servery表示當(dāng)前 JVM 作為調(diào)試服務(wù)端等待客戶端接入suspendn目標(biāo)程序啟動(dòng)時(shí)不掛起方便日常附加調(diào)試suspendy目標(biāo)程序會(huì)在啟動(dòng)點(diǎn)等待調(diào)試器連入適合排查啟動(dòng)階段問題address127.0.0.1:8787監(jiān)聽地址和端口建議只綁回環(huán)地址參數(shù)就緒后用 JDB 附加jdb -attach 127.0.0.1:8787如果連接成功會(huì)看到一堆初始化提示隨后進(jìn)入jdb提示符。這里有個(gè)值得記住的點(diǎn)suspendn和suspendy不是隨便選的。日常觀察運(yùn)行中的服務(wù)一定選n因?yàn)槌绦蛞坏﹩?dòng)就掛起業(yè)務(wù)就停了而調(diào)試 Spring 容器初始化、應(yīng)用啟動(dòng)配置這類代碼選y才能保證在main方法啟動(dòng)前就拿到斷點(diǎn)。2.3 啟動(dòng)配置文件與基礎(chǔ)命令習(xí)慣JDB 和很多命令行工具一樣支持從用戶主目錄下的.jdbrc文件讀取初始化命令。文件里每行放一條 JDB 命令啟動(dòng)時(shí)自動(dòng)執(zhí)行。我一般會(huì)把常用斷點(diǎn)放進(jìn)去省得每次都敲stop at com.example.OrderService:126但要注意這種自動(dòng)執(zhí)行可能在類還沒加載時(shí)就把斷點(diǎn)設(shè)置成 deferred 狀態(tài)也就是延遲斷點(diǎn)。大部分情況沒有問題因?yàn)?JVM 會(huì)在類加載完成后自動(dòng)把斷點(diǎn)裝上。只是如果你發(fā)現(xiàn)斷點(diǎn)一直沒命中優(yōu)先確認(rèn)是不是這類原因?；A(chǔ)命令里我會(huì)先記住四個(gè)help查看命令清單exit正常退出quit強(qiáng)制退出!執(zhí)行外部 shell 命令。用!可以在不退出 JDB 的情況下執(zhí)行top或者cat在排查現(xiàn)場非常順手。JDB 對(duì)命令大小寫不敏感但為了可讀性我還是保持小寫。3. 核心調(diào)試命令拆解斷點(diǎn)、線程、棧幀與步進(jìn)3.1 斷點(diǎn)命中代碼熱點(diǎn)的唯一入口斷點(diǎn)是 JDB 里最重要的動(dòng)作沒有斷點(diǎn)程序就會(huì)一直跑你沒有任何機(jī)會(huì)檢查內(nèi)部狀態(tài)。最常用的是行斷點(diǎn) stop at com.example.OrderService:126命令的關(guān)鍵字是stop at后面跟類名和行號(hào)。如果你只知道方法名可以用方法斷點(diǎn) stop in com.example.OrderService.batchProcess這個(gè)寫法適合記不住具體行號(hào)的場合但方法斷點(diǎn)會(huì)讓 JVM 在方法入口處插入更多事件性能開銷比行斷點(diǎn)大優(yōu)先級(jí)也低一些。做性能排查時(shí)我建議用行斷點(diǎn)因?yàn)槟憧梢园褦帱c(diǎn)精確放到循環(huán)體內(nèi)、條件分支里或者一個(gè)if判斷的右側(cè)直接觀察最窄的現(xiàn)場。查看和刪除斷點(diǎn)用clear clear clear com.example.OrderService:126不加參數(shù)時(shí)列出當(dāng)前全部斷點(diǎn)加了參數(shù)就刪除指定斷點(diǎn)。還有一個(gè)很實(shí)用的進(jìn)階玩法是條件斷點(diǎn) stop at com.example.OrderService:126 if orderList.size() 1000這個(gè)意思是只有orderList的大小超過 1000 時(shí)才暫停。條件斷點(diǎn)在性能復(fù)現(xiàn)中特別有用因?yàn)楹芏鄦栴}只在特定數(shù)據(jù)規(guī)模下暴露每次都手動(dòng)檢查太費(fèi)勁。要注意條件表達(dá)式里的變量必須在該行可見否則 JDB 會(huì)報(bào)變量找不到的錯(cuò)誤。3.2 線程在卡住現(xiàn)場里切換視角斷點(diǎn)命中后程序只是暫停在某個(gè)線程上。性能問題通常涉及多個(gè)線程比如一個(gè)線程池里有 10 個(gè)線程只有其中 3 個(gè)出現(xiàn)異常。這時(shí)候要先看線程列表 threads輸出會(huì)列出所有線程的調(diào)試編號(hào)、名稱、優(yōu)先級(jí)和狀態(tài)信息。注意這里的編號(hào)是 JDB 內(nèi)部的線程 ID不是操作系統(tǒng)看到的 native thread id。想切到某個(gè)線程深挖用thread命令 thread 12切換之后再用where看當(dāng)前線程的調(diào)用棧。如果嫌一條一條看太慢直接用where all等價(jià)于把全部線程的棧打出來效果接近一次簡化版的jstack。我在實(shí)際排查中會(huì)先執(zhí)行一次where all快速判斷哪些線程卡在業(yè)務(wù)代碼哪些線程在等待鎖然后再用thread精確切換過去。這里有個(gè)細(xì)節(jié)值得多說一句JDB 只有在線程掛起時(shí)才能安全地查看棧幀和變量。斷點(diǎn)命中的線程天然是掛起的所以你直接操作沒問題。但如果是手動(dòng)附加到運(yùn)行中的 JVM線程還在跑有些棧信息可能不好拿。遇到這種情況可以先用suspend把目標(biāo)線程掛起或者設(shè)置一個(gè)斷點(diǎn)讓代碼自然停住。3.3 棧幀、變量與表達(dá)式求值線程切換好之后最常用的三連是where、locals、print。where看調(diào)用棧棧頂是最當(dāng)前正在執(zhí)行的幀編號(hào)從[1]開始。如果想深入到某個(gè)具體棧幀JDB 提供up和down命令在幀之間移動(dòng)。這個(gè)動(dòng)作和 IDEA 調(diào)試面板里切棧幀是一個(gè)意思。locals打印當(dāng)前棧幀里的局部變量這是我最喜歡的命令。很多性能問題的答案就藏在局部變量里比如循環(huán)次數(shù)變量、集合大小、臨時(shí)對(duì)象引用。打印出來的結(jié)果一般是這樣args instance of java.lang.String[0] orderList instance of java.util.ArrayList只看引用還不夠要展開對(duì)象內(nèi)容用dump dump orderListdump會(huì)把對(duì)象的字段值遞歸展開讓你直接看到對(duì)象內(nèi)部狀態(tài)。如果只想看某個(gè)字段或者一個(gè)簡單的計(jì)算結(jié)果用print print orderList.size() print this.userId另外methods和fields可以分別查看類的方法簽名和字段定義適合在搞不清楚類結(jié)構(gòu)時(shí)臨時(shí)查一下。這里必須提醒一個(gè)很多人會(huì)踩的坑不要在print或者dump里隨便調(diào)用有副作用的 getter。調(diào)試器對(duì)表達(dá)式的求值有時(shí)會(huì)真實(shí)觸發(fā)目標(biāo)對(duì)象的方法。如果那個(gè)方法內(nèi)部有狀態(tài)修改或者在等待一把鎖輕則調(diào)試結(jié)果不準(zhǔn)重則直接讓線程卡死。優(yōu)先看字段再看簡單表達(dá)式最后再?zèng)Q定要不要調(diào)用方法。3.4 步進(jìn)、恢復(fù)與自動(dòng)執(zhí)行trace、monitor暫停之后并不一定只看局部變量你還可以用步進(jìn)命令觀察代碼執(zhí)行的走向。step進(jìn)入當(dāng)前行調(diào)用的方法next執(zhí)行當(dāng)前行并停在下一行step up直接跳出當(dāng)前方法回到調(diào)用方cont讓程序繼續(xù)運(yùn)行直到下一個(gè)斷點(diǎn)或退出。實(shí)際操作中next用的頻率比step高。因?yàn)樾阅芘挪榈闹攸c(diǎn)是“代碼怎么走到這一步”的而不是走得太深。一旦發(fā)現(xiàn)某個(gè)方法可疑再單獨(dú)用step進(jìn)入也不遲。還有兩個(gè)命令對(duì)性能分析特別有價(jià)值。第一個(gè)是monitor它可以在每次程序暫停時(shí)自動(dòng)執(zhí)行指定命令。例如 monitor where monitor locals這樣每次斷點(diǎn)命中JDB 都會(huì)自動(dòng)把棧和局部變量打出來省去了反復(fù)手動(dòng)敲命令的麻煩。第二個(gè)是trace用來開啟方法調(diào)用跟蹤。trace go methods會(huì)讓 JDB 在方法進(jìn)入和返回時(shí)打印日志看起來會(huì)非常啰嗦但是當(dāng)你想確認(rèn)一個(gè)調(diào)用鏈里到底重復(fù)執(zhí)行了多少次時(shí)它比斷點(diǎn)更直觀。我用trace時(shí)一般會(huì)把范圍縮小比如先在可疑方法入口設(shè)置斷點(diǎn)等命中后再開trace然后cont跑一小段時(shí)間及時(shí)用exit停掉不然日志量能大到把終端沖掉。4. 一個(gè)真實(shí)風(fēng)格的 JDB 實(shí)操案例模擬一個(gè)服務(wù)響應(yīng)變慢的調(diào)查4.1 案例背景為什么選擇 JDB 而不用直接看代碼為了把前面的命令串起來我準(zhǔn)備用一個(gè)虛擬的訂單聚合服務(wù)來說明。假設(shè)某個(gè)服務(wù)里有一個(gè)MockOrderService類batchProcess方法負(fù)責(zé)把一批訂單做聚合計(jì)算最近線上響應(yīng)變慢jstack顯示大量線程停留在這個(gè)方法里。光看棧信息你只能確認(rèn)“這個(gè)方法有問題”但不知道是訂單數(shù)量太大、某個(gè)字段為 null還是循環(huán)里在做重復(fù)計(jì)算。如果直接把代碼翻出來看一是代碼和線上版本未必一致二是很多狀態(tài)是在運(yùn)行期才產(chǎn)生的靜態(tài)代碼看不出來。用 JDB 的意義就是直接在運(yùn)行現(xiàn)場把方法暫停把變量值拿出來對(duì)照著代碼做判斷。4.2 步驟一啟動(dòng)目標(biāo) JVM 并掛載 JDB先啟動(dòng)模擬服務(wù)并打開調(diào)試端口java -agentlib:jdwptransportdt_socket,servery,suspendn,address127.0.0.1:8787 -classpath order-service.jar com.example.MockOrderService進(jìn)程起來后用jps -l確認(rèn) PID 存在再檢查調(diào)試端口有沒有監(jiān)聽ss -lntp | grep 8787然后另開一個(gè)終端執(zhí)行jdb -attach 127.0.0.1:8787看到j(luò)db提示符會(huì)話就建立了。因?yàn)閟uspendn目標(biāo)服務(wù)還在正常跑不會(huì)因?yàn)?JDB 接入就起飛。4.3 步驟二設(shè)置斷點(diǎn)并命中熱點(diǎn)在代碼里找到可疑的邏輯點(diǎn)。為了方便演示我假設(shè)batchProcess方法里有一個(gè)循環(huán)循環(huán)體內(nèi)部在動(dòng)態(tài)拼接 JSON 字符串行號(hào)對(duì)應(yīng) 126 行。先在 JDB 里設(shè)置斷點(diǎn) stop at com.example.MockOrderService:126然后讓程序恢復(fù)運(yùn)行 cont如果這時(shí)沒有流量進(jìn)來斷點(diǎn)不會(huì)觸發(fā)?？梢酝ㄟ^壓測或者手動(dòng)觸發(fā)接口的方式來制造調(diào)用。斷點(diǎn)命中后終端會(huì)顯示類似這樣的信息Breakpoint hit: http-nio-8080-exec-3 (id15) [1] com.example.MockOrderService.batchProcess (MockOrderService.java:126)命中的同時(shí)線程被掛起現(xiàn)在可以開始取證。4.4 步驟三查看線程和本地變量定位根因先看一下線程列表確認(rèn)當(dāng)前命中的線程編號(hào) threads輸出里能看到http-nio-8080-exec-3對(duì)應(yīng)的調(diào)試 id 是 15。切過去再看完整棧 thread 15 where接著打印局部變量 locals如果一切正常會(huì)看到orderList、startTime、resultMap這些變量。我想確認(rèn)訂單集合的大小直接執(zhí)行 print orderList.size()如果返回的數(shù)字異常比如一進(jìn)來就是幾萬條說明這個(gè)接口的輸入規(guī)模比設(shè)計(jì)預(yù)期大了很多。再深入看某個(gè)訂單對(duì)象 dump orderList.get(0)輸出會(huì)展開對(duì)象的字段比如status、amount、rawJson。這時(shí)候如果發(fā)現(xiàn)每個(gè)訂單都攜帶一大段原始 JSON循環(huán)里還在反復(fù)解析慢的原因就找到了不是框架的問題也不是 GC 的問題而是同一個(gè) JSON 在循環(huán)體里被解析了多次重復(fù)計(jì)算把 CPU 吃掉了。4.5 步驟四用 trace 和 monitor 驗(yàn)證調(diào)用鏈初步懷疑是重復(fù)解析后可以用trace驗(yàn)證。先把當(dāng)前斷點(diǎn)留著輸入 trace go methods然后cont繼續(xù)跑一小段時(shí)間再看終端里輸出的調(diào)用日志。日志會(huì)顯示MockOrderService.batchProcess內(nèi)部反復(fù)進(jìn)入某個(gè)解析方法而且同一個(gè)rawJson對(duì)應(yīng)的解析方法被調(diào)用的次數(shù)和訂單數(shù)量幾乎一樣。這個(gè)信號(hào)基本可以證實(shí)問題不在外部依賴而在循環(huán)內(nèi)部。為了讓每次命中斷點(diǎn)都自動(dòng)打印調(diào)用棧我還會(huì)加一個(gè)monitor monitor where之后每次遇到斷點(diǎn)棧信息自動(dòng)出來不用反復(fù)手動(dòng)敲。這招在連續(xù)觀察多個(gè)請(qǐng)求時(shí)非常省事特別適合判斷“是否每個(gè)請(qǐng)求都走到同一行”。4.6 步驟五修復(fù)和驗(yàn)證以及對(duì) JDB 能力的邊界說明定位到原因后修復(fù)思路很清晰把 JSON 解析從循環(huán)內(nèi)移到循環(huán)外或者做成緩存避免重復(fù)加工。修復(fù)后重新編譯再用同樣的方式啟動(dòng)和附加 JDB在同一個(gè)斷點(diǎn)觀察變量里的緩存命中情況確認(rèn)解析方法不再被高頻調(diào)用。這個(gè)案例也說明了 JDB 的能力邊界它不會(huì)告訴你“這個(gè)方法的平均耗時(shí)是多少毫秒”那是采樣工具的事它只會(huì)告訴你“這一秒這個(gè)方法內(nèi)部到底發(fā)生了什么”。所以在性能鏈路里JDB 和采樣工具是搭檔不是替代關(guān)系。5. JDB 與其它性能工具配合的正確姿勢5.1 JDB、jstack、jmap 報(bào)警時(shí)的工作分工我習(xí)慣把排查鏈路分成三步。第一步用jstack看線程棧判斷是業(yè)務(wù)線程卡住、鎖等待、還是 GC 線程異常第二步用jstat或jmap看堆判斷內(nèi)存壓力和對(duì)象分布第三步才是 JDB針對(duì)第一步和第二步里最可疑的點(diǎn)做暫停取證。工具主要作用弱點(diǎn)jstack快速抓全部線程棧只有棧沒有變量值jmap堆轉(zhuǎn)儲(chǔ)和對(duì)象統(tǒng)計(jì)分析對(duì)象存活鏈比較重jstat觀察 GC 和類加載狀態(tài)只統(tǒng)計(jì)不解釋業(yè)務(wù)邏輯JFR/ async-profiler做熱方法和采樣統(tǒng)計(jì)偏趨勢難以做單點(diǎn)暫停JDB把線程暫停檢查變量、斷點(diǎn)、調(diào)用鏈不能用于全量采樣例如前面那個(gè)案例如果沒有jstack先發(fā)現(xiàn)線程集中在batchProcess我就不可能在 JDB 里快速定位到那一行。反過來說如果只看jstack你也永遠(yuǎn)不會(huì)知道orderList.size()竟然那么大。工具之間是接力關(guān)系。5.2 腳本化 JDB 操作.jdbrc和輸入重定向調(diào)試動(dòng)作如果重復(fù)執(zhí)行就有腳本化的價(jià)值。JDB 初始化文件.jdbrc放在用戶主目錄下啟動(dòng)時(shí)自動(dòng)逐行執(zhí)行命令。我偶爾會(huì)在里面臨時(shí)放一個(gè)斷點(diǎn)stop at com.example.MockOrderService:126除初始化文件外JDB 也支持用標(biāo)準(zhǔn)輸入喂命令。管道輸入的方式可以嵌入自動(dòng)化腳本printf stop at com.example.MockOrderService:126\nrun\nwhere\nexit\n | jdb -classpath target/classes com.example.MockOrderService這種方式適合做回歸測試一旦某個(gè)構(gòu)造函數(shù)里面出現(xiàn)異常腳本能夠自動(dòng)把當(dāng)時(shí)的棧打出來不用人盯著鍵盤敲。自動(dòng)化演練場景里甚至可以先把.jdbrc準(zhǔn)備好再通過控制腳本去觸發(fā)流量。5.3 安全與運(yùn)維注意點(diǎn)JDB 附加到 JVM 的能力很強(qiáng)這意味著如果調(diào)試端口暴露在不安全的網(wǎng)絡(luò)里等于給攻擊者開了一扇門。我個(gè)人的原則是調(diào)試端口永遠(yuǎn)綁定127.0.0.1不要直接綁0.0.0.0或公網(wǎng) IP。需要跨機(jī)器調(diào)試時(shí)優(yōu)先用 SSH 隧道把本地端口轉(zhuǎn)發(fā)過去。調(diào)試結(jié)束后立即在目標(biāo) JVM 上恢復(fù)正常啟動(dòng)參數(shù)不要長期掛著調(diào)試代理。另一個(gè)容易被忽略的點(diǎn)是JDB 附加后即便沒有觸發(fā)斷點(diǎn)JVM 內(nèi)部也會(huì)產(chǎn)生調(diào)試事件相關(guān)的開銷。在高并發(fā)生產(chǎn)環(huán)境這種開銷會(huì)被放大。所以我的建議是“用完就走”不要在業(yè)務(wù)高峰期長時(shí)間保持調(diào)試會(huì)話。6. 踩坑記錄JDB 常見問題與排查技巧6.1 常見錯(cuò)誤現(xiàn)象速查下面這張表是我在實(shí)操中遇到過或者身邊同事踩過的坑整理出來方便速查。現(xiàn)象可能原因處理建議附加時(shí)提示Unable to connect調(diào)試端口沒開、綁定地址不對(duì)、防火墻攔截用jps -l確認(rèn)進(jìn)程用ss -lntp檢查端口附加成功但斷點(diǎn)一直不命中類還沒加載或斷點(diǎn)行號(hào)和線上源碼不一致先確認(rèn)代碼路徑執(zhí)行到了使用條件斷點(diǎn)縮小范圍stop at報(bào)No code at line指定行沒有字節(jié)碼或源碼版本不匹配用list查看當(dāng)前行號(hào)核對(duì) classpathlocals輸出為空當(dāng)前棧幀沒有局部變量或類編譯沒有帶調(diào)試信息用javac -g編譯確保線程已掛起print報(bào)異常表達(dá)式求值時(shí)調(diào)用了帶副作用的方法或?qū)ο鬄?null改用dump查看字段避免調(diào)用 getter線程切不過去線程 ID 記錯(cuò)或線程已終止用threads重新確認(rèn)編號(hào)日志量爆炸trace范圍太大沒及時(shí)關(guān)閉只在小范圍內(nèi)開啟用完exit退出會(huì)話這個(gè)表格里最高頻的問題其實(shí)是“附加成功但斷點(diǎn)不命中”。原因很多但最常見的是源碼和線上 jar 的行號(hào)對(duì)不上。排查前最好先確認(rèn)編譯產(chǎn)物對(duì)應(yīng)的源碼版本不要拿一份舊代碼去猜斷點(diǎn)位置。6.2 我在實(shí)操中的幾點(diǎn)心得最后聊幾個(gè)偏經(jīng)驗(yàn)的東西。第一JDB 最適合用來驗(yàn)證“假設(shè)”不適合用來做“探索”。也就是說你心里要先有一個(gè)大致判斷比如“會(huì)不會(huì)是這里循環(huán)次數(shù)太多”“會(huì)不會(huì)是某個(gè)字段沒初始化”然后再去設(shè)置斷點(diǎn)驗(yàn)證。如果完全沒有方向先用jstack和采樣工具縮小范圍再上 JDB。否則就是大海撈針。第二條件斷點(diǎn)雖然好用但性能開銷不小。JVM 每執(zhí)行到斷點(diǎn)行都要計(jì)算一次條件表達(dá)式如果那一行在熱路徑上調(diào)試期間的性能會(huì)明顯惡化。我的做法是把條件寫得盡量簡單比如只比較一個(gè)整數(shù)或一個(gè)布爾值不要寫復(fù)雜的字符串拼接或方法調(diào)用。第三monitor命令是容易被新手忽略的寶藏。它能把重復(fù)操作自動(dòng)化尤其適合查看多個(gè)請(qǐng)求連續(xù)進(jìn)入同一個(gè)熱點(diǎn)的情況。我在排查一批請(qǐng)求超時(shí)時(shí)就是用monitor where讓每個(gè)斷點(diǎn)自動(dòng)打棧然后連續(xù)觸發(fā)幾輪流量很快看出只有特定參數(shù)的請(qǐng)求會(huì)卡住。第四不要在重要環(huán)境中輕易嘗試不熟悉的 JDB 命令。調(diào)試器可以暫停線程、觸發(fā)方法調(diào)用甚至執(zhí)行redefine來修改類定義。這些操作在錯(cuò)誤的時(shí)間點(diǎn)上手可能造成線上進(jìn)程狀態(tài)異常。建議先在本地起一個(gè)最小 Demo把所有命令都過一遍再上真實(shí)環(huán)境。如果只能帶一條經(jīng)驗(yàn)走我會(huì)說JDB 不是一個(gè)花哨的工具但它值得你在每個(gè) Java 工程里留一個(gè)印象。性能定位的最后一步往往就是從“大概知道哪里有問題”到“確鑿看到問題現(xiàn)場”的過程而 JDB 就是幫你完成這最后一步的工具。