排查 Java 服务的性能问题命令行里常见的套路是先top看一眼负载再用jstack拉线程栈条件允许的话上jmap或者jcmd再看堆。这套流程能回答“哪里慢”但是常常回答不了“为什么慢”。我上次在一台只剩 SSH 的白盒服务器上排查接口延迟时发现线程栈反复提示某个方法在忙但光靠栈信息完全看不出是入参的问题还是循环的逻辑问题。这时候需要的不是采样工具而是一个能把程序暂停下来、让我把当前变量和调用关系看得明明白白的调试器。JDB 就是 JDK 自带的那把“手术刀”它没有图形界面、也不用装插件专治这种需要现场取证的场景。这篇文章就把我在真实排查中摸熟的 JDB 用法、踩坑记录和与其它性能工具配合的思路整理出来。1. 为什么说 JDB 是性能排查链路里最被低估的调试工具1.1 从定位到取证JDB 和性能工具的关系大多数人对 JDB 的第一印象是“命令行调试器”和性能分析没什么关系。这个印象不准确。性能工具可以分为两层第一层负责定位例如用 JFR 或 async-profiler 做 CPU 采样用jstat观察 GC 节奏用jstack抓线程卡点第二层负责取证也就是当你知道问题出在某个方法、某个对象或者某个线程状态时需要停下来把现场翻个底朝天。JDB 属于第二层。它本质上是 JDK 官方提供的 Java 调试工具底层走的是 JPDA 体系通过 JVM 的调试接口获取运行信息。IDE 里的断点、单步、变量检查本质上和它是同一套机制只不过 IDE 把命令封装成了图形按钮。换句话说你日常在 IDEA 里做的那套调试动作JDB 全部能做只是在命令行里完成。看重性能的人常犯一个误区觉得调试器只能在开发环境用。实际上在做性能分析的后期尤其是问题已经缩到某个类、某个方法甚至某一行时JDB 的价值非常大。比如一个接口响应突然变慢jstack只能看到线程停留在某处但你不知道它手里拿到的List到底有多大不知道某个字段是不是已经变成null不知道循环条件为什么一直没有退出。这些信息只有把程序暂停下来才能确认而 JDB 就是干这个的。1.2 哪些场景该用它哪些场景不该用它先说适合的场景。目标机器是无桌面环境的 Linux、容器或云主机没法开 IDE问题属于偶发需要等到某个条件满足时立刻观察现场程序启动阶段就有异常需要从第一条指令开始调试或者团队在做自动化故障演练希望用脚本把“设置断点、触发、抓栈、退出”变成一条命令。这些场景下 JDB 几乎是零成本的选择因为 JDK 装好之后它就躺在bin目录里。不太适合的场景也很明确需要统计热点方法耗时、需要生成火焰图、需要大面积采集样本时JDB 不是干这个的。它会让目标线程停下来逐帧检查状态这种“显微镜”式的操作不适合做全局扫描。原因在于 JDB 启动后会启用调试基础设施被附加的 JVM 内部会有额外事件处理的开销而且断点如果设置不当会让本来应该在热路径上的代码被强制挂起。所以正确的打开方式是先用采样工具画出轮廓再用 JDB 做定点解剖。2. 先把 JDB 跑起来两种启动方式与常用会话配置2.1 直接启动目标 Java 程序第一种方式是让 JDB 直接启动目标 Java 类适合调试本地可复现的问题。命令格式很简单jdb -classpath target/classes com.example.OrderService执行后会进入jdb提示符但此时目标程序还没有真正跑起来。新手最容易在这里踩坑直接输入run程序瞬间跑完还没反应过来调试就结束了。正确的做法是先设置好断点再发起运行。例如 stop at com.example.OrderService:126 runrun之后 JDB 才会拉起目标 JVM。如果程序一开始就命中断点会进入暂停状态这时候可以做栈和变量检查。如果程序能一路跑完最后 JDB 会提示目标进程退出整个调试会话当然也就结束了。直接启动时还可以带参数例如run arg1 arg2会把参数传给目标程序。对于有多个 classpath 的项目用-classpath指定即可。如果你有多个依赖 jar建议把它们都列在启动参数里否则 JDB 在解析某个断点类时会提示找不到类。2.2 挂到运行中的 JVMJDWP 参数是关键远程或线上问题的调试更多用的是第二种方式目标 JVM 已经跑着JDB 从外部附加进去。这里有一个前置步骤容易被忽略目标 JVM 必须要以调试模式启动也就是带上 JDWP 代理参数。我常用的启动参数是这样的java -agentlib:jdwptransportdt_socket,servery,suspendn,address127.0.0.1:8787 -jar order-service.jar每个参数的含义都比较固定我按自己的习惯解释一下。参数作用transportdt_socket指定调试通信走 Socket 协议servery表示当前 JVM 作为调试服务端等待客户端接入suspendn目标程序启动时不挂起方便日常附加调试suspendy目标程序会在启动点等待调试器连入适合排查启动阶段问题address127.0.0.1:8787监听地址和端口建议只绑回环地址参数就绪后用 JDB 附加jdb -attach 127.0.0.1:8787如果连接成功会看到一堆初始化提示随后进入jdb提示符。这里有个值得记住的点suspendn和suspendy不是随便选的。日常观察运行中的服务一定选n因为程序一旦启动就挂起业务就停了而调试 Spring 容器初始化、应用启动配置这类代码选y才能保证在main方法启动前就拿到断点。2.3 启动配置文件与基础命令习惯JDB 和很多命令行工具一样支持从用户主目录下的.jdbrc文件读取初始化命令。文件里每行放一条 JDB 命令启动时自动执行。我一般会把常用断点放进去省得每次都敲stop at com.example.OrderService:126但要注意这种自动执行可能在类还没加载时就把断点设置成 deferred 状态也就是延迟断点。大部分情况没有问题因为 JVM 会在类加载完成后自动把断点装上。只是如果你发现断点一直没命中优先确认是不是这类原因。基础命令里我会先记住四个help查看命令清单exit正常退出quit强制退出!执行外部 shell 命令。用!可以在不退出 JDB 的情况下执行top或者cat在排查现场非常顺手。JDB 对命令大小写不敏感但为了可读性我还是保持小写。3. 核心调试命令拆解断点、线程、栈帧与步进3.1 断点命中代码热点的唯一入口断点是 JDB 里最重要的动作没有断点程序就会一直跑你没有任何机会检查内部状态。最常用的是行断点 stop at com.example.OrderService:126命令的关键字是stop at后面跟类名和行号。如果你只知道方法名可以用方法断点 stop in com.example.OrderService.batchProcess这个写法适合记不住具体行号的场合但方法断点会让 JVM 在方法入口处插入更多事件性能开销比行断点大优先级也低一些。做性能排查时我建议用行断点因为你可以把断点精确放到循环体内、条件分支里或者一个if判断的右侧直接观察最窄的现场。查看和删除断点用clear clear clear com.example.OrderService:126不加参数时列出当前全部断点加了参数就删除指定断点。还有一个很实用的进阶玩法是条件断点 stop at com.example.OrderService:126 if orderList.size() 1000这个意思是只有orderList的大小超过 1000 时才暂停。条件断点在性能复现中特别有用因为很多问题只在特定数据规模下暴露每次都手动检查太费劲。要注意条件表达式里的变量必须在该行可见否则 JDB 会报变量找不到的错误。3.2 线程在卡住现场里切换视角断点命中后程序只是暂停在某个线程上。性能问题通常涉及多个线程比如一个线程池里有 10 个线程只有其中 3 个出现异常。这时候要先看线程列表 threads输出会列出所有线程的调试编号、名称、优先级和状态信息。注意这里的编号是 JDB 内部的线程 ID不是操作系统看到的 native thread id。想切到某个线程深挖用thread命令 thread 12切换之后再用where看当前线程的调用栈。如果嫌一条一条看太慢直接用where all等价于把全部线程的栈打出来效果接近一次简化版的jstack。我在实际排查中会先执行一次where all快速判断哪些线程卡在业务代码哪些线程在等待锁然后再用thread精确切换过去。这里有个细节值得多说一句JDB 只有在线程挂起时才能安全地查看栈帧和变量。断点命中的线程天然是挂起的所以你直接操作没问题。但如果是手动附加到运行中的 JVM线程还在跑有些栈信息可能不好拿。遇到这种情况可以先用suspend把目标线程挂起或者设置一个断点让代码自然停住。3.3 栈帧、变量与表达式求值线程切换好之后最常用的三连是where、locals、print。where看调用栈栈顶是最当前正在执行的帧编号从[1]开始。如果想深入到某个具体栈帧JDB 提供up和down命令在帧之间移动。这个动作和 IDEA 调试面板里切栈帧是一个意思。locals打印当前栈帧里的局部变量这是我最喜欢的命令。很多性能问题的答案就藏在局部变量里比如循环次数变量、集合大小、临时对象引用。打印出来的结果一般是这样args instance of java.lang.String[0] orderList instance of java.util.ArrayList只看引用还不够要展开对象内容用dump dump orderListdump会把对象的字段值递归展开让你直接看到对象内部状态。如果只想看某个字段或者一个简单的计算结果用print print orderList.size() print this.userId另外methods和fields可以分别查看类的方法签名和字段定义适合在搞不清楚类结构时临时查一下。这里必须提醒一个很多人会踩的坑不要在print或者dump里随便调用有副作用的 getter。调试器对表达式的求值有时会真实触发目标对象的方法。如果那个方法内部有状态修改或者在等待一把锁轻则调试结果不准重则直接让线程卡死。优先看字段再看简单表达式最后再决定要不要调用方法。3.4 步进、恢复与自动执行trace、monitor暂停之后并不一定只看局部变量你还可以用步进命令观察代码执行的走向。step进入当前行调用的方法next执行当前行并停在下一行step up直接跳出当前方法回到调用方cont让程序继续运行直到下一个断点或退出。实际操作中next用的频率比step高。因为性能排查的重点是“代码怎么走到这一步”的而不是走得太深。一旦发现某个方法可疑再单独用step进入也不迟。还有两个命令对性能分析特别有价值。第一个是monitor它可以在每次程序暂停时自动执行指定命令。例如 monitor where monitor locals这样每次断点命中JDB 都会自动把栈和局部变量打出来省去了反复手动敲命令的麻烦。第二个是trace用来开启方法调用跟踪。trace go methods会让 JDB 在方法进入和返回时打印日志看起来会非常啰嗦但是当你想确认一个调用链里到底重复执行了多少次时它比断点更直观。我用trace时一般会把范围缩小比如先在可疑方法入口设置断点等命中后再开trace然后cont跑一小段时间及时用exit停掉不然日志量能大到把终端冲掉。4. 一个真实风格的 JDB 实操案例模拟一个服务响应变慢的调查4.1 案例背景为什么选择 JDB 而不用直接看代码为了把前面的命令串起来我准备用一个虚拟的订单聚合服务来说明。假设某个服务里有一个MockOrderService类batchProcess方法负责把一批订单做聚合计算最近线上响应变慢jstack显示大量线程停留在这个方法里。光看栈信息你只能确认“这个方法有问题”但不知道是订单数量太大、某个字段为 null还是循环里在做重复计算。如果直接把代码翻出来看一是代码和线上版本未必一致二是很多状态是在运行期才产生的静态代码看不出来。用 JDB 的意义就是直接在运行现场把方法暂停把变量值拿出来对照着代码做判断。4.2 步骤一启动目标 JVM 并挂载 JDB先启动模拟服务并打开调试端口java -agentlib:jdwptransportdt_socket,servery,suspendn,address127.0.0.1:8787 -classpath order-service.jar com.example.MockOrderService进程起来后用jps -l确认 PID 存在再检查调试端口有没有监听ss -lntp | grep 8787然后另开一个终端执行jdb -attach 127.0.0.1:8787看到jdb提示符会话就建立了。因为suspendn目标服务还在正常跑不会因为 JDB 接入就起飞。4.3 步骤二设置断点并命中热点在代码里找到可疑的逻辑点。为了方便演示我假设batchProcess方法里有一个循环循环体内部在动态拼接 JSON 字符串行号对应 126 行。先在 JDB 里设置断点 stop at com.example.MockOrderService:126然后让程序恢复运行 cont如果这时没有流量进来断点不会触发。可以通过压测或者手动触发接口的方式来制造调用。断点命中后终端会显示类似这样的信息Breakpoint hit: http-nio-8080-exec-3 (id15) [1] com.example.MockOrderService.batchProcess (MockOrderService.java:126)命中的同时线程被挂起现在可以开始取证。4.4 步骤三查看线程和本地变量定位根因先看一下线程列表确认当前命中的线程编号 threads输出里能看到http-nio-8080-exec-3对应的调试 id 是 15。切过去再看完整栈 thread 15 where接着打印局部变量 locals如果一切正常会看到orderList、startTime、resultMap这些变量。我想确认订单集合的大小直接执行 print orderList.size()如果返回的数字异常比如一进来就是几万条说明这个接口的输入规模比设计预期大了很多。再深入看某个订单对象 dump orderList.get(0)输出会展开对象的字段比如status、amount、rawJson。这时候如果发现每个订单都携带一大段原始 JSON循环里还在反复解析慢的原因就找到了不是框架的问题也不是 GC 的问题而是同一个 JSON 在循环体里被解析了多次重复计算把 CPU 吃掉了。4.5 步骤四用 trace 和 monitor 验证调用链初步怀疑是重复解析后可以用trace验证。先把当前断点留着输入 trace go methods然后cont继续跑一小段时间再看终端里输出的调用日志。日志会显示MockOrderService.batchProcess内部反复进入某个解析方法而且同一个rawJson对应的解析方法被调用的次数和订单数量几乎一样。这个信号基本可以证实问题不在外部依赖而在循环内部。为了让每次命中断点都自动打印调用栈我还会加一个monitor monitor where之后每次遇到断点栈信息自动出来不用反复手动敲。这招在连续观察多个请求时非常省事特别适合判断“是否每个请求都走到同一行”。4.6 步骤五修复和验证以及对 JDB 能力的边界说明定位到原因后修复思路很清晰把 JSON 解析从循环内移到循环外或者做成缓存避免重复加工。修复后重新编译再用同样的方式启动和附加 JDB在同一个断点观察变量里的缓存命中情况确认解析方法不再被高频调用。这个案例也说明了 JDB 的能力边界它不会告诉你“这个方法的平均耗时是多少毫秒”那是采样工具的事它只会告诉你“这一秒这个方法内部到底发生了什么”。所以在性能链路里JDB 和采样工具是搭档不是替代关系。5. JDB 与其它性能工具配合的正确姿势5.1 JDB、jstack、jmap 报警时的工作分工我习惯把排查链路分成三步。第一步用jstack看线程栈判断是业务线程卡住、锁等待、还是 GC 线程异常第二步用jstat或jmap看堆判断内存压力和对象分布第三步才是 JDB针对第一步和第二步里最可疑的点做暂停取证。工具主要作用弱点jstack快速抓全部线程栈只有栈没有变量值jmap堆转储和对象统计分析对象存活链比较重jstat观察 GC 和类加载状态只统计不解释业务逻辑JFR/ async-profiler做热方法和采样统计偏趋势难以做单点暂停JDB把线程暂停检查变量、断点、调用链不能用于全量采样例如前面那个案例如果没有jstack先发现线程集中在batchProcess我就不可能在 JDB 里快速定位到那一行。反过来说如果只看jstack你也永远不会知道orderList.size()竟然那么大。工具之间是接力关系。5.2 脚本化 JDB 操作.jdbrc和输入重定向调试动作如果重复执行就有脚本化的价值。JDB 初始化文件.jdbrc放在用户主目录下启动时自动逐行执行命令。我偶尔会在里面临时放一个断点stop at com.example.MockOrderService:126除初始化文件外JDB 也支持用标准输入喂命令。管道输入的方式可以嵌入自动化脚本printf stop at com.example.MockOrderService:126\nrun\nwhere\nexit\n | jdb -classpath target/classes com.example.MockOrderService这种方式适合做回归测试一旦某个构造函数里面出现异常脚本能够自动把当时的栈打出来不用人盯着键盘敲。自动化演练场景里甚至可以先把.jdbrc准备好再通过控制脚本去触发流量。5.3 安全与运维注意点JDB 附加到 JVM 的能力很强这意味着如果调试端口暴露在不安全的网络里等于给攻击者开了一扇门。我个人的原则是调试端口永远绑定127.0.0.1不要直接绑0.0.0.0或公网 IP。需要跨机器调试时优先用 SSH 隧道把本地端口转发过去。调试结束后立即在目标 JVM 上恢复正常启动参数不要长期挂着调试代理。另一个容易被忽略的点是JDB 附加后即便没有触发断点JVM 内部也会产生调试事件相关的开销。在高并发生产环境这种开销会被放大。所以我的建议是“用完就走”不要在业务高峰期长时间保持调试会话。6. 踩坑记录JDB 常见问题与排查技巧6.1 常见错误现象速查下面这张表是我在实操中遇到过或者身边同事踩过的坑整理出来方便速查。现象可能原因处理建议附加时提示Unable to connect调试端口没开、绑定地址不对、防火墙拦截用jps -l确认进程用ss -lntp检查端口附加成功但断点一直不命中类还没加载或断点行号和线上源码不一致先确认代码路径执行到了使用条件断点缩小范围stop at报No code at line指定行没有字节码或源码版本不匹配用list查看当前行号核对 classpathlocals输出为空当前栈帧没有局部变量或类编译没有带调试信息用javac -g编译确保线程已挂起print报异常表达式求值时调用了带副作用的方法或对象为 null改用dump查看字段避免调用 getter线程切不过去线程 ID 记错或线程已终止用threads重新确认编号日志量爆炸trace范围太大没及时关闭只在小范围内开启用完exit退出会话这个表格里最高频的问题其实是“附加成功但断点不命中”。原因很多但最常见的是源码和线上 jar 的行号对不上。排查前最好先确认编译产物对应的源码版本不要拿一份旧代码去猜断点位置。6.2 我在实操中的几点心得最后聊几个偏经验的东西。第一JDB 最适合用来验证“假设”不适合用来做“探索”。也就是说你心里要先有一个大致判断比如“会不会是这里循环次数太多”“会不会是某个字段没初始化”然后再去设置断点验证。如果完全没有方向先用jstack和采样工具缩小范围再上 JDB。否则就是大海捞针。第二条件断点虽然好用但性能开销不小。JVM 每执行到断点行都要计算一次条件表达式如果那一行在热路径上调试期间的性能会明显恶化。我的做法是把条件写得尽量简单比如只比较一个整数或一个布尔值不要写复杂的字符串拼接或方法调用。第三monitor命令是容易被新手忽略的宝藏。它能把重复操作自动化尤其适合查看多个请求连续进入同一个热点的情况。我在排查一批请求超时时就是用monitor where让每个断点自动打栈然后连续触发几轮流量很快看出只有特定参数的请求会卡住。第四不要在重要环境中轻易尝试不熟悉的 JDB 命令。调试器可以暂停线程、触发方法调用甚至执行redefine来修改类定义。这些操作在错误的时间点上手可能造成线上进程状态异常。建议先在本地起一个最小 Demo把所有命令都过一遍再上真实环境。如果只能带一条经验走我会说JDB 不是一个花哨的工具但它值得你在每个 Java 工程里留一个印象。性能定位的最后一步往往就是从“大概知道哪里有问题”到“确凿看到问题现场”的过程而 JDB 就是帮你完成这最后一步的工具。