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