continue会恢复所有stopped线程，导致调试失控；应使用thread apply continue精确唤醒指定线程，配合info threads确认id，避免误唤醒其他线程。
gdb里用 continue 会恢复所有线程，不是你想要的
默认情况下，continue、step、next 这些命令在多线程下是“全量恢复”：所有处于 STOPPED 状态的线程都会运行。如果你只挂起了某个线程（比如用 signal SIGSTOP 或系统级暂停），又只想让它继续，直接 continue 就会把其他本在等待的线程也一并唤醒——这常导致竞态复现失败或调试逻辑错乱。
用 thread apply <id> continue</id> 精确控制单个线程
这是最直接有效的办法。先用 info threads 查看线程列表，注意左侧编号（如 2、3），再对目标线程单独发 continue：
gdb$ info threads Id Target Id Frame * 1 Thread 0x7ffff7fcf740 (LWP 12345) "a.out" 0x00007ffff7b9e54d in __GI___pthread_timedjoin_ex (...) 2 Thread 0x7ffff77ce700 (LWP 12346) "a.out" 0x00007ffff7b9e54d in __GI___pthread_timedjoin_ex (...) 3 Thread 0x7ffff6fcd700 (LWP 12347) "a.out" 0x00007ffff7b9e54d in __GI___pthread_timedjoin_ex (...) <p>gdb$ thread apply 3 continue</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4025" title="C++ 算法竞赛自动化测试数据生成与校验框架"><img src="https://img.php.cn/upload/skill/000/000/081/178988956499722.jpg" alt="C++ 算法竞赛自动化测试数据生成与校验框架" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill4025" title="C++ 算法竞赛自动化测试数据生成与校验框架" class="overflowclass">C++ 算法竞赛自动化测试数据生成与校验框架</a> <p class="overflowclass">根据原题生成新题面、验证器及完整测试数据，自动套用 testlib 模板，用于用户要求生成测试数据时。</p> </div> <a rel="nofollow" href="/xiazai/skill4025" title="C++ 算法竞赛自动化测试数据生成与校验框架" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>
-
thread apply <id><command></command></id>中的<id></id>是info threads显示的左侧数字，不是 LWP PID - 该命令只影响指定线程，其余线程保持原状态（
STOPPED或running不变） - 如果线程当前被信号阻塞（如
SIGSTOP），thread apply <id> continue</id>仍能生效；但若它卡在不可中断的内核态（如D状态），则无法唤醒
别误用 schedulelock on，它不解决“恢复单个线程”问题
有人看到文档里有 set scheduler-locking on，以为能锁住其他线程只跑当前线程——其实不是。它只限制 gdb 在单步/继续时“不自动切换线程”，但一旦当前线程阻塞（比如等 mutex、sleep、read），gdb 仍可能调度其他线程（取决于 set scheduler-locking 的实际模式和 gdb 版本），而且它完全不干预已处于 STOPPED 状态的线程是否恢复。
-
set scheduler-locking step：仅对step/next生效，不影响continue -
set scheduler-locking on：gdb 6.8+ 行为不一致，某些版本下仍可能切线程，不可靠 - 它不能替代
thread apply <id> continue</id>，两者解决的是不同层面的问题
注意线程状态与 gdb 断点的交互细节
即使你用 thread apply 3 continue 唤醒了线程 3，它也可能立刻停在下一个断点——尤其是全局断点（比如函数入口）。这时候你得确认断点是否对所有线程生效：
- 用
info breakpoints查看断点的Enb列和What列，带thread 3条件的断点才只影响该线程 - 设置线程限定断点：
break func_name thread 3或break *0x123456 thread 3 - 若线程 3 恢复后没反应，检查它是否真的在运行：用
thread 3切过去，再bt或info registers看 PC 是否在动
真正容易被忽略的是：gdb 对线程状态的感知依赖于内核通知，有时线程已从 SIGSTOP 恢复，但 gdb 缓存的状态还没刷新，表现为 info threads 仍显示 Stopped。此时可尝试 thread 3 + continue 强制同步一次。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
