jdb是JDK自带的轻量级命令行调试器，支持断点、单步、查变量，但功能有限：不支持条件/异常断点，不显示局部变量类型，对Lambda、泛型等Java 8+特性支持差，且需全限定类名和正确-classpath配置。
命令行本身不支持设置断点或查看变量——OpenJDK 没有内置的命令行调试器。你看到的 java -jar app.jar 或 javac 都是纯执行/编译工具，不带交互式调试能力。真正在命令行“调试”JDK 本身（比如改了 HotSpot 源码想验证行为），必须走编译 + 启动调试器的路径，而不是在终端里敲个命令就断点。
为什么 jdb 几乎没人用
jdb 是 JDK 自带的命令行调试器，理论上能设断点、查变量，但实际几乎不可用：
- 不支持条件断点、日志断点、异常断点等现代调试必需功能
- 变量显示极简，
print obj.field不能展开嵌套对象，dump输出混乱难读 - 没有表达式求值（
Evaluate Expression）、没有堆栈帧回退（Drop Frame） - 对 Lambda、泛型、内联方法等 Java 8+ 特性支持差，常显示
???或直接跳过 - 和 IDE 调试体验差距太大，连
System.out.println都比它直观
真正可行的命令行级调试：用 gdb / lldb 调试 JVM 本地代码
如果你的目标是调试 OpenJDK 本身的 C++ 层（如 GC 算法、JNI 调用、HotSpot 解释器），那确实得用命令行工具，但不是 jdb：
- 必须用
slowdebug编译 JDK（bash configure --with-debug-level=slowdebug），否则符号全被优化掉 - 启动时加
-XX:+PrintGCDetails -XX:+UnlockDiagnosticVMOptions -XX:+Debugging等开关打开诊断输出 - 用
gdb --args ./build/*/images/jdk/bin/java -jar your-app.jar启动，再用break os::breakpoint或break universe.cpp:123下断点 -
info registers、print *thread、bt查堆栈——这些才是命令行真·调试
IDE 调试 JDK 源码时，“命令行”只是入口
多数人想“在命令行调试 JDK”，其实是想绕过 IDE 图形界面，用脚本方式启动调试会话。这时的关键是：
- 确保你的 JDK 构建产物（
./build/*/images/jdk）已配置进JAVA_HOME - 用
java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005 -jar app.jar启动目标进程 - 在 IDEA 或 VS Code 中配置 Remote JVM Debug，host=localhost，port=5005，然后 Attach
- 此时你在 IDE 里设的所有断点（含 JDK 源码里的
java.lang.String::length）、Watch 表达式、Variables 视图，全部生效——命令行只负责“让 JVM 开个口子”，调试逻辑全在 IDE 侧
最易被忽略的一点：JDK 源码调试的前提不是“会敲命令”，而是构建时是否保留了完整调试信息。--with-debug-level=slowdebug 不是可选项，是硬门槛；没它，gdb 连函数名都看不到，IDE 里断点全灰掉——这时候再熟的快捷键也没用。
