C++ 调试实战（07）：多线程调试——线程切换、死锁定位与数据竞争
单线程程序出了问题，大不了一步一步走。多线程程序就麻烦了：断点在哪个线程上命中？单步时别的线程在干什么？程序卡住不动了，到底是谁在等谁？而且多线程 bug 常常「一调试就消失」——调试器改变了线程执行的节奏。这一篇讲多线程调试的基本功：查看和切换线程、给所有线程打印调用栈、attach 到一个卡死的进程定位死锁，以及用 ThreadSanitizer 抓数据竞争。
这是「C++ 调试实战」系列的第 7 篇。本篇的所有命令都建立在前几篇的基础上：线程切换之后，每个线程里的调用栈、变量，查看方式和单线程完全一样。
编译多线程程序时，GCC 需要链接线程库。较新的 glibc 已经把 pthread 并入了 libc，直接编译就行；老系统上需要加 -pthread。
一、示例一：两个线程累加同一个计数器
1 | // race.cpp |
两个线程各加 10 万次，期望结果是 20 万。运行两次：
1 | $ g++ -std=c++20 -g -O0 race.cpp -o race.linux |
（和前几篇一样，Linux 版可执行文件带 .linux 后缀，macOS 版带 .mac 后缀，下面输出里的线程名就是程序名。）
每次结果都不一样，而且都远小于 20 万。先别急着修，用它来熟悉多线程调试命令。
二、查看与切换线程
2.1 断点在哪个线程命中
1 | (gdb) break add_many |
和单线程程序相比，多了几条信息：
[New Thread ... (LWP 17)]：新线程创建了。LWP（Light Weight Process）是 Linux 内核里的线程 ID；[Switching to Thread ...]：断点命中的线程和之前选中的不同，GDB 自动切换过去；Thread 2 "race.linux" hit Breakpoint 1：命中断点的是 2 号线程（GDB 内部编号），线程名是race.linux（默认就是程序名）。
2.2 info threads：列出所有线程
1 | (gdb) info threads |
| 列 | 含义 |
|---|---|
* |
当前选中的线程 |
Id |
GDB 的线程编号，切换线程时用它 |
Target Id |
系统层面的线程标识：pthread_t 的值、LWP 号、线程名 |
Frame |
这个线程当前停在哪个函数 |
1 号线程是主线程，此时正在 clone3 里——它正在创建第二个工作线程。
要点：GDB 默认是「全停」模式（all-stop），任何一个线程停下来，所有线程都会停下来。 所以你看到的是整个进程在同一时刻的快照。
继续运行，第二个线程也命中了断点：
1 | (gdb) continue |
现在有 3 个线程：主线程已经进入 t1.join() 在等待（停在 __syscall_cancel_arch，这是等待类系统调用的入口），两个工作线程都在 add_many 的第 7 行。
2.3 thread N：切换线程
1 | (gdb) thread 2 |
（这段输出来自下面的死锁示例。）切换之后，bt、frame、print、info locals 都是针对这个线程的。
LLDB 的对应命令：
| 操作 | GDB | LLDB |
|---|---|---|
| 列出线程 | info threads |
thread list |
| 切换线程 | thread 2 |
thread select 2 |
| 所有线程的调用栈 | thread apply all bt |
bt all（thread backtrace all） |
| 在指定线程执行命令 | thread apply 2 3 print i |
—— |
2.4 只在某个线程上停
断点可以限定线程，只有指定线程执行到这里时才停：
1 | (gdb) break race.cpp:8 thread 2 |
LLDB 用 breakpoint set -f race.cpp -l 8 -t <线程ID>，或者用 -T <线程名> 按线程名过滤。给线程起名（Linux 上用 pthread_setname_np）能让多线程调试轻松很多，info threads 里一眼就能看出哪个线程是干什么的。
2.5 单步时别让其他线程乱跑
在一个线程里 next，默认情况下其他线程也会跟着运行。如果你正在单步观察共享变量，它可能在你两次单步之间被别的线程改掉。GDB 可以锁住调度器：
1 | (gdb) set scheduler-locking step |
| 取值 | 效果 |
|---|---|
off |
所有线程都自由运行 |
step |
单步（next / step）时只运行当前线程；continue 时所有线程都运行 |
on |
任何时候都只运行当前线程 |
注意 on 模式下如果当前线程在等一个锁、而持有锁的线程被锁住不能运行，程序就「卡死」了——这是你自己造成的，不是程序的 bug。
LLDB 的单步命令有 --run-mode 选项：thread step-over --run-mode this-thread。
三、示例二：程序卡住了——定位死锁
1 | // threads.cpp |
| 行号 | 代码 |
|---|---|
| 10 / 12 | worker1：先锁 mtx_a，再锁 mtx_b |
| 17 / 19 | worker2：先锁 mtx_b，再锁 mtx_a |
| 26 | t1.join(); |
运行之后，程序什么也不输出，也不退出，就这么卡着。这是经典的死锁：worker1 拿着 mtx_a 等 mtx_b，worker2 拿着 mtx_b 等 mtx_a，谁也等不到。（sleep_for 是为了让两个线程几乎必然各自拿到第一把锁，稳定复现死锁。）
3.1 两种进入调试器的方式
方式 1：在调试器里运行，卡住后按 Ctrl+C。 GDB 和 LLDB 都会中断程序，停在当前位置，然后就可以查看了。
方式 2：attach 到已经在运行的进程。 这是实际工作中更常见的情况：服务已经跑了很久，突然不响应了。你不能重启它（重启就丢失现场了），而是把调试器「挂」上去：
1 | $ ./threads.linux & # 模拟一个已经卡住的进程 |
LLDB 是 lldb -p <PID>，或者按进程名 lldb -n threads.mac。
attach 需要权限，两个常见问题：
- Linux 上报
ptrace: Operation not permitted：很多发行版开启了 Yama 安全模块，/proc/sys/kernel/yama/ptrace_scope为 1 时，只允许调试自己启动的子进程。临时解决办法是用sudo gdb -p <PID>；Docker 里则需要--cap-add=SYS_PTRACE（第 00 篇）； - macOS 上：attach 到别的进程需要开发者权限，首次使用时系统会弹窗要求授权，或者需要
sudo。系统自带的程序受系统完整性保护（SIP），不能 attach。
attach 成功后，进程会被暂停；调试结束时用 detach 让进程继续运行，或者直接 quit（GDB 会询问是否 detach）。
3.2 看所有线程在干什么
attach 之后，第一个命令就是 info threads：
1 | (gdb) info threads |
GDB 很贴心地把地址翻译成了符号：线程 2 在等 <mtx_a>，线程 3 在等 <mtx_b>。futex_wait 是 Linux 上线程阻塞等待锁的底层系统调用。
再用 thread apply all bt 看每个线程完整的调用栈（省略了标准库内部的部分帧）：
1 | (gdb) thread apply all bt |
输出里的
[PAC]是 ARM64 的指针认证（Pointer Authentication）标记，表示这个返回地址是被签名过的，在 x86_64 上不会出现。
用第 04 篇的读栈方法——找第一个属于自己代码的帧：
| 线程 | 自己代码的帧 | 在做什么 |
|---|---|---|
| 3（LWP 9） | #7 worker1 () at threads.cpp:12 |
在第 12 行等 mtx_b |
| 2（LWP 10） | #7 worker2 () at threads.cpp:19 |
在第 19 行等 mtx_a |
| 1（LWP 7） | #7 main () at threads.cpp:26 |
在 t1.join() 等线程 1 结束 |
3.3 找到锁的持有者
知道了谁在等哪把锁，还要知道每把锁被谁拿着。在 Linux 上，std::mutex 底层是 pthread_mutex_t，它的内部结构里记录了持有者的 LWP：
1 | (gdb) thread 2 |
（这次 attach 的是重新运行的进程，所以地址和上面不同，LWP 编号恰好一致。）
把线索串起来：
1 | 线程 3（LWP 9，worker1） ──持有──▶ mtx_a ◀──等待── 线程 2（LWP 10，worker2） |
一个完美的环：循环等待。这就是死锁的铁证。
_M_mutex.__data.__owner是 libstdc++ 和 glibc 的内部实现细节，不同平台不一样（macOS 的 libc++ 就没有这个字段）。但思路是通用的：先看每个线程在等什么（调用栈），再想办法确认谁持有什么。实在找不到持有者字段，就在每个线程里看它的调用栈上有哪些lock_guard已经构造完成。
3.4 LLDB 版
在 macOS 上 attach：
1 | (lldb) process attach --pid 7106 |
macOS 上等待互斥锁的系统调用叫 __psynch_mutexwait。线程 2 在 worker1 第 12 行等地址 0x...590040 的锁，线程 3 在 worker2 第 19 行等 0x...590000 的锁（两个全局 mutex 相邻存放，前者是 mtx_b，后者是 mtx_a，可以用 p &mtx_a 确认）。结论和 Linux 上完全一致。
﹍ 和 ﹉ 符号表示 LLDB 把中间几个标准库的帧折叠了（第 7、8 帧）。切到自己代码的帧看源码：
1 | (lldb) thread select 2 |
3.5 修复
死锁的根源是两个线程加锁顺序相反。修复方法：
- 所有线程按统一的顺序加锁（都先
mtx_a再mtx_b）； - 或者用 C++17 的
std::scoped_lock，一次性锁住多把锁，它内部用死锁避免算法：
1 | void worker1() { |
四、数据竞争：ThreadSanitizer
回到第一个例子 race.cpp。计数器结果不对的原因是 ++counter 不是原子操作，它实际上是「读、加一、写回」三步，两个线程交错执行时会丢失更新。
这类 bug 用调试器很难抓：你在 ++counter 上下断点，线程就被暂停了，时序完全被改变；而且它不崩溃、不卡死，只是结果「偶尔不对」。专门的工具是 ThreadSanitizer（TSan）：
1 | g++ -std=c++20 -g -O0 -fsanitize=thread race.cpp -o race.tsan |
1 | ================== |
（为了篇幅省略了 BuildId 和标准库的栈帧。）报告的结构和 ASan 很像：
| 部分 | 含义 |
|---|---|
Read of size 4 ... by thread T2 |
线程 T2 在 race.cpp:8 读了这块内存 |
Previous write ... by thread T1 |
此前线程 T1 在 race.cpp:8 写过同一块内存，两次访问之间没有任何同步 |
Location is global 'counter' |
出问题的变量是全局变量 counter |
这正是 ++counter 那一行。有意思的是，这次运行打印出了正确的 200000——TSan 的插桩改变了程序的执行节奏，竞争碰巧没有造成丢失更新。但 TSan 照样报告了问题：它检测的是「两个线程访问同一内存且没有同步」这个事实本身，不依赖于这次运行是否真的算错了。这正是它比「多跑几次看结果」可靠的地方。
修复：把 counter 改成 std::atomic<int>，或者用 std::mutex 保护。
TSan 的注意事项：
- 不能和 ASan 同时使用；
- 运行开销比 ASan 大，程序可能慢 5～15 倍，内存占用也更多；
- 同样只能发现实际执行到的竞争，所以测试要覆盖到并发路径。
五、多线程调试的几条经验
| 经验 | 说明 |
|---|---|
| 程序卡住，先抓全体线程的栈 | thread apply all bt（LLDB：bt all）是定位死锁、卡死的第一步；可以把输出保存下来慢慢分析 |
| 不要急着重启 | 卡死的进程就是最好的现场，先 attach，看完再说 |
| 给线程起名字 | info threads 里一眼能认出每个线程是干什么的 |
| 调试器会改变时序 | 断点、单步都会让线程停下来，竞争类 bug 可能因此消失。这类问题优先用 TSan |
| 单步时锁住调度器 | 想专注观察一个线程时，set scheduler-locking step |
| 崩溃在别的线程 | 多线程程序崩溃时，GDB / LLDB 会自动切到出问题的线程，直接 bt 即可；core dump 里也包含所有线程 |
一个实用的小脚本：不用进入交互界面，直接抓取某个进程所有线程的调用栈并保存下来：
1 | gdb -p <PID> -batch -ex "thread apply all bt" > stacks.txt |
-batch 表示执行完命令就退出（并 detach，进程继续运行）。线上服务偶发卡顿时，隔几秒抓一次，对比几份栈，就能看出线程长时间卡在哪里。
六、小结
| 需求 | GDB | LLDB |
|---|---|---|
| 列出线程 | info threads |
thread list |
| 切换线程 | thread N |
thread select N |
| 所有线程的调用栈 | thread apply all bt |
bt all |
| 指定线程的断点 | break 位置 thread N |
br set ... -t 线程ID |
| 单步时只跑当前线程 | set scheduler-locking step |
thread step-over --run-mode this-thread |
| attach 到进程 | gdb -p PID |
lldb -p PID / lldb -n 进程名 |
| 脱离进程 | detach |
detach |
| 检测数据竞争 | -fsanitize=thread |
-fsanitize=thread |
C++ 调试实战系列第 7 篇完。下一篇：IDE 图形化调试与速查表——VS Code 调试配置，以及 GDB / LLDB 命令对照总表。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 WALL-E's Blog！
相关推荐
2026-10-01
C++ 调试实战（01）：断点——让程序停在你想停的地方
调试的第一步永远是「让程序停下来」。断点（breakpoint）就是你插在代码里的一面小旗：程序跑到这里就暂停，把现场交给你检查。这一篇把断点的各种用法讲全：按函数、按行号、条件断点、临时断点、忽略次数，以及启用、禁用、删除，最后再介绍两种「停下来但不打扰你」的断点——命中时自动执行命令的断点和 dprintf。 这是「C++ 调试实战」系列的第 1 篇。示例程序沿用第 00 篇的 orders.cpp，Linux 版用 g++ -std=c++20 -g -O0 orders.cpp -o orders 编译，macOS 版编译为 orders.mac。 先回顾一下 orders.cpp 的关键行号： 行号 代码 11–17 double line_total(const Order& o)：12 行计算小计，14 行打九折，16 行 return total; 19–25 double sum_orders(const std::vector<Order>& orders)：22 行 sum += line_total(o)...
2026-10-08
C++ 调试实战（08）：IDE 图形化调试与 GDB / LLDB 速查表
前面七篇全是命令行。命令行是调试的「内功」：服务器上、容器里、SSH 远程，只有命令行可用；很多高级功能（dprintf、watch -l、thread apply all bt）也只有命令行里才用得顺手。但日常写代码时，在编辑器里点一下行号就下断点、鼠标悬停就看变量值，确实更舒服。这一篇介绍 VS Code 里的图形化调试配置，以及它和命令行的对应关系，最后把整个系列的命令整理成一张速查表。 这是「C++ 调试实战」系列的第 8 篇，也是最后一篇。IDE 的调试界面本质上只是 GDB / LLDB 的一层「外壳」，理解了前面的命令，图形界面上的每个按钮都知道它在做什么。 一、IDE 调试的本质VS Code、CLion、Xcode、Qt Creator 这些 IDE 自己都不会调试程序，它们是在后台启动 GDB 或 LLDB，把你在界面上的操作翻译成调试器命令： 你在界面上做的 背后执行的命令（大致相当于） 点击行号左侧下断点 break orders.cpp:22 右键断点 → 编辑条件 condition 1 o.quantity >...
2026-10-02
C++ 调试实战（02）：运行与单步——next、step、finish 与函数返回值
程序停在断点之后，下一步就是「往前走」：一行一行地走（next），钻进函数里走（step），在函数里看够了就一口气跑到函数返回并看看返回值（finish），或者直接跳出一个很长的循环（until）。这几个命令组合起来，就是调试器里最常用的「方向盘」。 这是「C++ 调试实战」系列的第 2 篇。示例程序仍然是第 00 篇的 orders.cpp。上一篇讲了断点，这一篇讲停下来之后怎么走。 关键行号回顾： 行号 代码 12 / 14 / 16 line_total()：计算小计 / 打九折 / return total; 21 / 22 / 24 sum_orders()：for 循环 / sum += line_total(o); / return sum; 33 main()：double total = sum_orders(orders); 一、先把几个命令放在一起看 命令 GDB LLDB 一句话说明 启动 run / start run st...
2026-10-03
C++ 调试实战（03）：查看与修改变量——print、display、STL 容器与调用函数
程序停下来之后，最常做的事就是「看看现在变量是多少」。调试器在这方面比 printf 强太多：随时想看哪个就看哪个，结构体、容器一次全展开，可以按十六进制、二进制显示，可以算表达式，可以每走一步自动打印，甚至可以直接改掉变量的值、调用程序里的函数，看看「如果是这样会怎样」。 这是「C++ 调试实战」系列的第 3 篇。示例程序仍然是第 00 篇的 orders.cpp。前两篇讲了断点和单步，这一篇讲停下来之后怎么看数据。 本篇大部分操作都停在 line_total 的第 16 行 return total;（break orders.cpp:16，然后 run），第一次命中时处理的是 apple（3 件 × 2.5）。 一、print：打印变量和表达式1.1 基本用法1234(gdb) print o$1 = (const Order &) @0xaaaaaaad3020: {name = "apple", quantity = 3, price = 2.5}(gdb) print o.quantity * o.price$2...
2026-10-04
C++ 调试实战（04）：调用栈与栈帧——我是怎么走到这里的
程序停在某个函数里，你往往还想知道：是谁调用了它？调用链上每一层当时的参数是多少？ 一个函数被十个地方调用，出错的是哪一次？回答这些问题要靠调用栈（call stack）。这一篇用一个递归求阶乘的程序，把 backtrace、切换栈帧、查看栈帧信息，以及「finish 作用于选中帧」这些细节讲清楚。 这是「C++ 调试实战」系列的第 4 篇。前面几篇的命令都是在「当前函数」里操作，这一篇开始把视野扩展到整条调用链。 一、示例程序123456789101112131415// fact.cpp#include <cstdio>int factorial(int n) { if (n <= 1) { return 1; } return n * factorial(n - 1);}int main() { int result = factorial(5); std::printf("5! = %d\n", result); return ...
2026-10-06
C++ 调试实战（06）：崩溃现场分析——段错误、core dump 与 AddressSanitizer
Segmentation fault (core dumped)——大概是每个 C++ 程序员见过最多的一行报错。它只告诉你「程序崩了」，不告诉你崩在哪、为什么崩。这一篇讲三种找到答案的办法：在调试器里运行，崩溃时直接停在现场；事后用 core dump 还原现场；以及用 AddressSanitizer 在内存错误发生的那一刻就抓住它，哪怕这个错误并没有让程序崩溃。 这是「C++ 调试实战」系列的第 6 篇。本篇会大量用到第 04 篇的调用栈知识：崩溃分析的第一步永远是 bt。 一、示例：一个忘了判空的指针123456789101112131415161718192021222324252627// crash.cpp#include <cstdio>#include <string>struct Config { std::string name; int retries;};Config* find_config(const std::string& key) { if (key == ...
