jdb是openjdk自带的轻量级命令行调试器，支持启动新进程调试（如jdb -classpath . helloworld）或附加到已开启jdwp调试端口的运行中java进程（如jdb -connect com.sun.jdi.socketattach:hostname=localhost,port=8000），需目标jvm启动时配置-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000。

jdb 是 OpenJDK 自带的命令行调试器，不依赖 IDE，适合快速定位问题、分析无源码的 JAR 包行为，或在受限环境（如 ARM64 服务器、容器内）做轻量级调试。它不是万能替代品，但当你无法启动 IDE、没有符号表、或需要复现某个 JVM 进程崩溃前的状态时，jdb 往往是唯一可用的本地调试入口。

怎么启动 jdb 并连接到正在运行的 Java 进程

jdb 支持两种模式：启动新进程调试（launch mode），或附加到已有进程（attach mode）。后者更常用，尤其用于排查生产环境卡顿、死锁或异常堆栈不全的问题。

• 启动新进程调试需显式指定主类和参数，例如：jdb -classpath . HelloWorld，然后在 jdb 提示符下输入 run
• 附加到已有进程必须确保目标 JVM 启动时开启了调试支持（即加了 -agentlib:jdwp 参数），否则 jdb 无法连接
• 常见错误现象：java.io.IOException: handshake failed - connection prematurely closed，基本等于目标 JVM 没开调试端口或防火墙拦截了端口

正确启动被调试进程的关键参数示例：

jvm -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:8000 -jar myapp.jar

注意：suspend=n 表示不阻塞启动，address=*:8000 允许远程连接（若只本机调试可简化为 address=8000）；OpenJDK 9+ 推荐用更简洁写法：-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000

jdb 断点设置与执行控制的实际用法

jdb 的断点机制基于类名+行号或方法签名，不支持条件断点（如 if x > 100），也不支持修改变量值后继续执行（即无 set 赋值能力），这些限制常被忽略，导致调试中途卡住。

• stop in java.util.ArrayList.add：在方法入口设断点（支持重载，但不会区分参数类型，需手动确认命中的是哪个）
• stop at MyClass:25：在 MyClass.java 第 25 行设断点（要求 class 文件含调试信息，即编译时用了 -g）
• run：仅对 launch mode 有效；attach mode 下用 run 会报错，应改用 run 不适用，此时需靠目标进程自然触发断点
• step / next / step up：分别对应单步进入、单步跳过、跳出当前方法；step 进入 JDK 内部（如 HashMap.put）时，若无 src.zip 或调试符号，会显示“no source found”，只能靠 dump 查看局部变量

容易踩的坑：

OpenJDK 24

下载

• 误以为 stop in SomeClass.someMethod 能自动匹配所有重载——实际只会停在第一个解析到的方法，可能不是你想要的那个
• 在没有 -g 编译的 class 上用 stop at，提示 “Line number not available”，只能退回到 stop in 方法级断点
• locals 命令只显示当前栈帧的局部变量，且不包括已优化掉的变量（如循环计数器被 JIT 移除后就不可见）

为什么 jdb 在 ARM64 Linux 上经常找不到 javac 或 tools.jar

OpenJDK 的 ARM64 构建版（尤其是 JDK 8）常被精简：很多发行版打包时直接删掉了 tools.jar、sa-jdi.jar、甚至 bin/jdb 本身。这不是 bug，而是历史包袱——ARM64 JDK 8 官方早已停止维护，社区构建多以“能跑 java”为优先，调试工具链被视为可选。

• 检查 jdb 是否真实存在：ls $JAVA_HOME/bin/jdb；若不存在，说明该 JDK 包不含调试器
• 若 jdb 存在但报 Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/tools/jdi/Connector，大概率是 tools.jar 缺失或未被 jdb 脚本自动加入 classpath
• 解决办法不是重装系统 JDK，而是换用完整版 ARM64 OpenJDK 8，例如 Adoptium Temurin 8u352-b08 或 Amazon Corretto 8.352.08.1，它们明确包含 jdb、javac 和全部 *.jar 工具依赖

一个典型验证命令：

$JAVA_HOME/bin/jdb -version

输出应为类似 Java Debugger Version 1.8.0_352；若报 command not found 或 NoClassDefFoundError，就别往下试断点了，先解决环境完整性。

什么时候该放弃 jdb，转用 jhsdb 或 jstack

jdb 本质是 JDWP 协议客户端，强依赖目标 JVM 处于“可通信”状态。一旦进程卡死、陷入 native 死锁、或因 OOM 被内核 kill，jdb 就完全失效。这时候得切到另一套工具链。

• jstack <pid></pid>：最轻量，无需调试参数，直接读取 JVM 线程快照；适用于快速判断死锁（输出含 deadlock 标记）或线程阻塞位置
• jhsdb jstack --pid <pid></pid>：比 jstack 更底层，支持从 core dump 分析（--core core.1234 --exe /path/to/java），且不依赖目标 JVM 是否存活
• jhsdb clhsdb：交互式内存分析，可查对象分布、GC Roots、甚至反汇编热点方法——但要求 JVM 启动时加了 -XX:+UseServiceabilityAgent（默认关闭，且部分 OpenJDK 8 ARM64 构建版根本不支持 SA）

关键区别在于：jdb 是“活体调试”，jhsdb 是“尸体解剖”。线上出问题第一反应不该是连 jdb，而是先 jstack 抓快照，再决定是否重启前 dump core 供 jhsdb 深挖。

真正难的从来不是学会 jdb 的命令，而是在 JVM 已经不响应、日志只有一行 OutOfMemoryError、且你手头只有 SSH 和一个阉割版 JDK 的时候，知道该用哪个命令、从哪一行输出里抓到那条关键线索。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南