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