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查看局部变量
容易踩的坑：
立即学习“Java免费学习笔记（深入）”；
- 误以为
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>：最轻量，无需调试参数，直接读取 JVM 线程快照；适用于快速判断死锁（输出含deadlock标记）或线程阻塞位置 -
jhsdb jstack --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 的时候，知道该用哪个命令、从哪一行输出里抓到那条关键线索。
