gdb中continue默认恢复所有线程，但受scheduler-locking设置影响；若为on或step，则仅当前线程继续，需set scheduler-locking off才能批量恢复。
gdb 中 continue 默认只恢复当前线程？
不是的——continue（或简写 c）在 gdb 里默认恢复**所有线程**，但前提是其他线程没被显式暂停。问题常出在：你用 break 打了断点，多个线程都停在同一个位置，而你执行 c 后只有当前线程继续跑，其余仍卡着。这不是 continue 的行为异常，而是因为 gdb 默认启用了“线程调试模式”下的 set scheduler-locking，它会锁住调度器，让其他线程不推进。
检查当前状态：show scheduler-locking。如果输出是 on 或 step，那就解释了为什么“批量恢复”失效。
-
set scheduler-locking off—— 恢复所有线程（最常用） -
set scheduler-locking on—— 只运行当前线程，其他线程冻结（调试竞态时有用） -
set scheduler-locking step—— 仅在单步（next/step）时锁定，c不锁
如何确认哪些线程被断点拦住了？
不能光靠 info threads 看状态为 Stopped 就认为它们都卡在断点上——有些可能在系统调用、信号或死锁中。真正可靠的判断方式是结合 thread apply all bt 和断点位置比对：
- 先用
info breakpoints确认断点编号和命中次数（disp列显示 hit count） - 再执行
thread apply all bt -n 3（限制栈帧数防刷屏），看各线程是否都停在同一个__GI___pthread_timedjoin_ex、std::this_thread::sleep_for或你的目标函数入口 - 特别注意状态为
Target stopped但无栈帧的线程——可能是被信号中断，需用signal SIGCONT单独唤醒
批量恢复的可靠命令组合
单纯 continue 不够稳，尤其在线程数多、断点密集时。推荐用三步法确保全部释放：
- 关闭调度锁定：
set scheduler-locking off - 清除已触发但未处理的断点事件（避免重复中断）：
delete或disable对应断点，或用ignore <code>BPNUM1000000 忽略后续命中 - 最后执行：
continue—— 此时所有线程都会从各自断点处继续
如果仍有个别线程不动，大概率是它被信号阻塞（比如 SIGSTOP）或处于不可中断睡眠（D 状态），这时得切到该线程：thread <code>TID，再手动 signal SIGCONT 或检查 info registers 是否卡在内核态。
用 thread apply all continue 会怎样？
这个命令**不会批量恢复**，反而会报错或无效。因为 continue 是一个“恢复执行”动作，不是线程上下文切换指令；thread apply all 是对每个线程依次执行某命令，但 continue 在非当前线程上调用会被 gdb 忽略（gdb 文档明确说明：only the current thread is continued）。实测结果通常是：只对当前线程生效，其余线程状态不变，且终端可能打印一堆 Cannot execute this command while the target is running. 类提示。
所以别走捷径——set scheduler-locking off + continue 是唯一稳定路径。复杂点在于：如果你在条件断点里用了线程局部变量（如 $pc == 0x401234 && $_thread == 2），恢复后其他线程可能立刻再次命中，得提前评估断点逻辑是否真需要跨线程隔离。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
