set scheduler-locking step 是最常用且有效的线程单步调试方法，可确保 step/next 时仅当前线程执行一步，其余线程完全冻结；但 continue/finish/until 会自动解除锁定。
set scheduler-locking step 是最常用且有效的做法
默认情况下，next 或 step 一执行，所有线程都会动——哪怕你只对当前线程单步，其它线程也可能执行几十行甚至完成整个循环。这不是 bug，是 GDB 的全停止（all-stop）模式默认行为。set scheduler-locking step 能让单步时“锁住”其他线程：只有当前线程走一步，其余线程完全不动。
注意：step 和 next 在该模式下才真正“单线程单步”；但 continue、finish、until 会自动解除锁定，其它线程随之恢复运行——这是设计使然，不是配置失效。
-
set scheduler-locking step后用step→ 当前线程进函数，其它线程冻结 -
set scheduler-locking step后用next→ 当前线程跳过函数调用，其它线程仍冻结 - 一旦敲
continue，GDB 自动切回off行为（所有线程继续），无需手动 reset - 若想彻底禁止其它线程运行（连
continue都不放行），改用set scheduler-locking on，但此时你必须手动thread 2+continue才能让指定线程跑，操作成本高
thread apply ID next/step 不等于“只单步当前线程”
很多人误以为 thread apply 2 next 就能安全单步 2 号线程，其实不然。这个命令只是“向线程 2 发送 next 指令”，但 GDB 仍按全停止模式响应：它会让线程 2 执行一行，同时允许其它线程也执行（通常是若干行，不可控）。所以它不能替代 set scheduler-locking step。
真正安全的单步路径只有一条：先 thread 2 切到目标线程，再 set scheduler-locking step，最后用 step 或 next。
立即学习“C++免费学习笔记（深入）”；
-
thread apply 2 step→ 线程 2 单步，但线程 1、3 也会随机跑一段，可能破坏竞态现场 -
thread 2→ 把 2 设为当前线程（*标记出现） -
set scheduler-locking step→ 锁定调度器行为 - 此时
step/next才真正只动线程 2
non-stop 模式下 scheduler-locking 无效，慎用
新版 GDB（≥7.2）支持 set non-stop on，开启后线程可独立暂停/继续。但这时 set scheduler-locking 完全被忽略——GDB 认为“既然各线程已解耦，就不需要锁调度器了”。如果你开了 non-stop，又想单步某线程，唯一办法是：
-
thread 2切入 -
step或next（此时其它线程保持暂停，因为 non-stop 下它们各自状态独立） - 但要注意：
info threads输出里会有Running/Stopped状态标记，别误把“没显示 *”当成没选中 - non-stop 模式下
continue默认只继续当前线程，不像 all-stop 那样“一键全放”，这点反而更符合直觉
容易被忽略的关键细节
线程 ID（info threads 显示的 Id）和系统线程 TID（/proc/pid/task/ 下看到的数字）不是一回事，thread 2 中的 2 是 GDB 自己编号，每次调试会变；而断点绑定用的 break line thread 2 里的 2 也是这个 ID，不是 pthread_self() 返回值。
另外，step 进函数后，如果该函数内有 pthread_create，新线程创建瞬间就会被 GDB 捕获并出现在 info threads 里——但此时它大概率卡在 libc 的 clone 调用里，还没执行你的业务代码第一行。别急着切过去，先确认它是否已进入目标函数。
