gdb多线程调试无真正“非阻塞模式”，默认为all-stop模式；set scheduler-locking off/on/step仅控制执行命令时其他线程是否运行，本质是调度器锁而非运行模型切换。
gdb 调试多线程时默认就是“阻塞式”执行
很多人误以为 gdb 有“非阻塞模式”，其实没有。gdb 本身不提供让线程真正并发、互不干扰地跑起来的“非阻塞调试模式”。它只有 set scheduler-locking 这一套机制来控制其他线程是否被暂停——本质是「调度器锁」，不是线程运行模型切换。
set scheduler-locking on / off / step 的真实含义
这个命令决定的是：当你对当前线程执行 next、step、continue 等操作时，其它线程要不要跟着停/动。
-
set scheduler-locking off：默认值。执行continue时所有线程都继续；单步时其它线程也可能被调度（但 gdb 不保证它们不抢断点） -
set scheduler-locking on：当前线程单步或继续时，其它线程被强制挂起（即“锁住调度器”），直到你显式切到别的线程再操作 -
set scheduler-locking step：只在执行step或next时锁住其它线程；一旦执行完这一步，其它线程立刻恢复运行
注意：on 和 step 都不是“非阻塞”，而是“更可控的阻塞”。真正想让线程自由并发跑，只能用 off，但此时你无法稳定复现竞态问题。
为什么不能像普通程序那样“非阻塞调试”
因为调试器必须插入断点、拦截信号、读写寄存器和内存——这些操作天然需要暂停目标线程甚至整个进程。Linux 下 ptrace 机制决定了 gdb 对每个线程的控制是独占的。所谓“非阻塞”，在调试语境下其实是：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 你不想手动干预其它线程，就设
set scheduler-locking off - 你怕其它线程干扰当前线程的单步逻辑，就用
step模式 - 你想逐个检查每个线程状态，就配合
info threads+thread N切换
没有命令能让你启动 gdb 后“所有线程自动跑、我只监听某个条件触发再介入”——那属于 trace 工具（如 perf、lttng）或 sanitizer（如 ThreadSanitizer）的范畴，不是 gdb 的设计目标。
容易忽略的关键点：编译和断点设置直接影响行为
即使设置了 set scheduler-locking off，如果你在共享变量访问处打了普通断点（比如 break counter::add_one），所有线程走到那里都会停——这不是调度器锁的问题，而是断点本身全局生效。要避免这点，得用线程限定断点：
-
break counter::add_one thread 2：只让线程 2 在此处中断 -
break data.cpp:42 thread 3 if idx == 5：线程 3 满足条件才停
否则，你以为“开了 off 就非阻塞”，结果所有线程一进临界区全卡住，反而更难观察真实并发行为。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
