多线程应用的测试与调试

从“测试通过不等于已证明”开始

整本书你学会了让多个厨师高效地一起干活。可真到了忙时，后厨偶尔会冒出怪事：两个厨师同时改同一张单子，菜出错了；两人各攥着对方要的工具僵在原地，谁也动不了；又或者两人在窄过道里反复对向让路，一起往左、一起往右，谁也过不去。这一章就回答：这些乱子怎么分门别类，又怎么把它们揪出来？

最让人头疼的是：这些乱子时有时无。你忙的时候它犯，你一停下来盯着看，它又乖乖不犯了——你越想抓现行，它越不出现。靠「多跑几次碰运气」根本不可靠。

所以得换思路：先写清什么结果算对、什么进展算活着，再控制关键线程在同一窗口起跑，记录失败种子与操作历史，并用动态检测器补充证据。测试能发现错误，却无法穷尽所有调度；“这次没报错”永远不是正确性证明。

先认脸：并发 bug 分门别类

调试的第一步不是动手改，而是看症状对号入座——不同的并发 bug 长相不同，查法也不同。下面这张速查图把全书出现过的几类摆在一起，每类配「症状 / 常见成因 / 往哪查」，先扫一眼记住它们的脸：

逐个点名（都呼应前面各章，本章把它们统一当「要测试、要调试的 bug 源」）：

条件竞争： 正确性依赖线程之间的相对时序，而时序不受你控制——结果时对时错、换台机器或加点负载就变样。它常常是更具体问题（如数据竞争、破坏不变量）的统称。

死锁： 多个执行单元形成等待环，环中每个成员都要等另一个成员先完成。互斥量顺序相反只是一个例子；future 相互等待、线程池任务耗尽也会死锁。相关线程通常阻塞，但进程里其他线程仍可能占用 CPU。

活锁： 线程没被锁住、反而都在忙——检测到冲突就退避重试，可退避动作总同时发生，于是反复礼让、谁也没真正前进。它和死锁是这一章重点要分清的一对，下一节专门对比。

数据竞争： 两个潜在并发的操作冲突、至少一个不是原子操作，且没有 happens-before 把它们排出先后——在普通 C++ 程序中这是未定义行为。两个原子操作不会仅因并发访问同一对象而构成数据竞争，但错误的内存序仍可能破坏更高层协议。

破坏不变量： 对象本该始终满足某条「不变量」，可一个线程更新到一半的「半成品」状态被别的线程看见（或被异常打断），不变量就破了——表现为断言失败、链表断裂这类非法状态。

记住这五张脸，遇到诡异现象就能快速缩小范围。下面把最容易混的死锁与活锁单独拎出来对比。

一对孪生陷阱：死锁 vs 活锁

死锁和活锁都表现为高层操作没有进展。核心区别是：死锁参与者在等待环里无法继续，活锁参与者仍在执行与改变状态却长期不完成操作。下面的最小示意中，死锁线程阻塞、活锁线程忙重试；真实系统还可能有其他工作线程，因此不能只看进程总 CPU 就下结论。

猜一猜：死锁和活锁，哪个 CPU 占用率高？

在这张最小图里，活锁一侧的忙重试会比阻塞等待占用更多 CPU，所以预测答案是活锁更高。但这只是线索：带 sleep 的退避型活锁可能 CPU 很低，局部死锁也可能与其他忙线程并存。现场要结合超时后的全线程栈、锁/等待图、重试计数和已完成操作计数判断。

互斥量死锁可通过统一锁顺序或一次性获取多锁来消除；其他等待环要重构任务依赖、保留可执行容量或禁止池内同步等待。活锁则要保证退避最终有一方获胜，例如指数随机退避、仲裁者或有界重试后的升级路径；随机化降低概率，但不等于形式上的进展保证。

怎么把乱子揪出来：审查、结构化测试、消毒器

定位并发 bug 有三件趁手的工具，从「人看」到「机器自动抓」：

第一是代码审查清单：人脑过一遍——这块共享数据被几个线程碰？都加锁了吗？加锁顺序一致吗？某个函数抛异常时，它该交的结果交了没（不然等它的线程会永远等下去）？审查抓的是「设计层」的疏漏，便宜又有效。

第二是结构化测试：先用顺序参考模型验证业务语义，再显式构造并发窗口。用屏障让线程同时到达关键操作，给每个等待设置截止时间，记录线程数、随机种子、操作与返回历史；失败时保存全线程栈与进展计数。并发容器还应把历史交给顺序模型或线性化检查器验证，不能只看最终总数。

第三是动态检测器，代表是 ThreadSanitizer（TSan）。它在本次执行覆盖到冲突访问时，用 happens-before 关系判断两次冲突访问是否被同步排出先后：

读懂第 ③④ 拍就懂了核心：TSan 把本次观察到的冲突访问与同步事件放进 happens-before 模型；若冲突未被同步排序，就报告数据竞争及两侧栈。它是动态检测，只看执行过的路径；零报告只能说明这次覆盖未发现，不能证明没有竞态、死锁、原子协议错误或未覆盖的数据竞争。典型开销约为 5～15 倍时间、5～10 倍内存，并且通常需要相关代码都被插桩，所以应放在专门测试任务中。

写代码时就为「可测试」着想

最省事的调试，是让 bug 一开始就难以藏身。为可测试性设计有几条朴素原则：

• 减少共享状态：能不共享就不共享。让线程多在自己的数据上独立干活、最后再合并，需要同步的地方就少，能出竞态的地方也就少。
• 把并发依赖抽出来、可注入 / 可替换：别把「开线程」「取当前时间」「调度」这些硬编码进业务逻辑。抽成接口，测试时换成可控的假实现（比如让「时钟」按你的剧本走），就能确定性地复现特定时序。
• 让逻辑能单线程先测对：把「算什么」和「怎么并行地算」拆开。纯逻辑（如「累加器加 1」「容器插入」）应该能脱离线程、在单线程下被穷尽测试。逻辑都对了，并发测试才只需盯「同步」这一层。
• 让等待与进展可观测：阻塞接口接受超时或停止令牌，关键状态有低扰动计数器，测试能判断“尚未完成”“已失败”“已停止”，而不是永久挂住 CI。

这三条的共同主线：缩小要测的并发面。共享越少、依赖越能替换、逻辑越能单独验证，留给并发 bug 的藏身之处就越小。

故意把它逼出来：压力测试与 heisenbug

并发 bug 的偶发性，是测试它最大的敌人。heisenbug 会在你加 printf、挂调试器或启用插桩后改变表现；TSan 也会扰动时序，只是它能从已执行访问中检测竞争，不能被描述成“不改语义、每次必抓”。

压力测试 用来扩大调度覆盖，而不是盲目“开远超核数线程”。至少覆盖 1、2、接近硬件并行度、适度过度订阅和生产上限；用屏障对齐关键窗口，记录随机种子，设置超时并持续校验不变量。线程太多可能只测到调度器抖动或资源耗尽，反而遮住目标协议。

性能测试：与正确性检测分开

TSan 构建的插桩与内存开销会彻底改变时序和吞吐，不能拿来做性能结论。性能测试应使用接近发布的优化构建，固定硬件、亲和性与数据集，先测单线程基线，再画 1/2/4/... 核的吞吐和尾延迟曲线，同时记录 CPU、上下文切换、内存带宽与锁等待。

性能回归也要区分延迟、吞吐、扩展性和资源上限：平均吞吐提高不代表 P99 延迟更好，8 核加速不代表 64 核仍扩展。每组结果要有预热、多次样本和波动范围；正确性套件先通过，性能套件再回答“值不值得并行”。

上手玩一玩这三张图

本章三张图分别管「分清两种卡住」「看懂工具」「学会分类」，配合 §6 代码一起玩：

• 死锁 vs 活锁 ``（主 Demo）：单步看左栏等待环冻结，右栏持续重试却进度归零。CPU 差异只属于这张最小示例；真实现场还要看线程栈、等待图和完成计数。
• TSan 抓数据竞争 <TsanDetectionDiagram />：单步看「A 写 / B 读、无同步 → 插桩记录访问与同步 → 比对 happens-before → 报告冲突两侧」。再指出图的边界：只有本次执行且被插桩的路径可被分析。
• 并发 bug 速查 ``：对照五类 bug 的症状 / 成因 / 往哪查，做 §8 选型题前先把五张脸记牢。

代码对照：有数据竞争的版本 vs 加锁修复版

type D 的代码对照要把「前后两个方案的差异行」摆在一起看。先看有数据竞争的翻车版——四个线程同时对一个无保护的全局变量做读-改-写：

#include <thread>
#include <vector>
 
int run_unsafe() {
    int counter = 0;  // 生命周期覆盖所有已 join 的线程，但没有同步保护
    std::vector<std::thread> pool;
    for (int t = 0; t < 4; ++t) {
        pool.emplace_back([&counter] {
            for (int i = 0; i < 100000; ++i) ++counter;  // 数据竞争：UB
        });
    }
    for (auto& th : pool) th.join();
    return counter;  // 不能用任何一次观测结果解释这个含 UB 的程序
}

++counter 与其他线程的 ++counter 是未排序的冲突访问，直接构成数据竞争与未定义行为。“丢更新”是常见现象，但标准不限制程序只表现为计数偏小；编译器可基于无数据竞争假设做优化，所以不能拿某次输出反推语义。

用 -fsanitize=thread 编译并运行这条路径时，若冲突访问在本次执行中被观察到，TSan 会报告类似：

WARNING: ThreadSanitizer: data race (pid=12345)
  Write of size 4 at 0x... by thread T2:
    #0 run_unsafe()::$_0::operator()()  race.cpp:8
  Previous write of size 4 at 0x... by thread T1:
    #0 run_unsafe()::$_0::operator()()  race.cpp:8
  Location is stack of main thread

报告会给出冲突访问与线程创建栈，但一次零报告仍不能证明正确。下面用同一局部状态与局部互斥量重写，避免全局测试状态跨用例泄漏：

#include <mutex>
#include <thread>
#include <vector>
 
int run_safe() {
    int counter = 0;
    std::mutex mutex;
    std::vector<std::thread> pool;
    for (int t = 0; t < 4; ++t) {
        pool.emplace_back([&] {
            for (int i = 0; i < 100000; ++i) {
                std::lock_guard<std::mutex> lock(mutex);
                ++counter;
            }
        });
    }
    for (auto& th : pool) th.join();
    return counter;  // join 后读取，预期 400000
}

代码对照：结构化测试骨架（先逻辑、再压测）

光修好还不够——要有测试守住它，且测试本身要「结构化」：先单线程测逻辑、再多线程压测。下面是一个可直接编译运行的骨架（被测对象用原子计数器，逻辑简单到一眼能验对）：

#include <atomic>
#include <cassert>
#include <thread>
#include <vector>
 
// 被测对象：一个线程安全计数器（用原子，逻辑很简单）
struct Counter {
    std::atomic<int> n{0};
    void inc() { n.fetch_add(1, std::memory_order_relaxed); }
    int get() const { return n.load(std::memory_order_relaxed); }
};
 
// ① 先单线程测「逻辑」对不对：不开线程，纯验证 inc/get 的行为
void test_logic_single_thread() {
    Counter c;
    assert(c.get() == 0);
    c.inc();
    c.inc();
    assert(c.get() == 2);  // 逻辑错（如忘了 +1）在这里就该挂，省得去并发里猜
}

第一步刻意不开线程：如果连单线程下 inc 两次都不等于 2，那是逻辑写错了，跟并发毫无关系——在这一步揪出来，比在多线程的一团乱麻里猜要省心得多。逻辑过了，第二步才上高压，逼出偶发的并发 bug：

#include <atomic>
#include <cassert>
#include <thread>
#include <vector>
 
struct Counter {  // 同上一段被测对象：线程安全计数器
    std::atomic<int> n{0};
    void inc() { n.fetch_add(1, std::memory_order_relaxed); }
    int get() const { return n.load(std::memory_order_relaxed); }
};
 
void run_counter_case(int thread_count) {
    constexpr int kPerThread = 100000;
    Counter c;
    std::vector<std::thread> pool;
    for (int t = 0; t < thread_count; ++t) {
        pool.emplace_back([&c] {
            for (int i = 0; i < kPerThread; ++i) c.inc();
        });
    }
    for (auto& th : pool) th.join();
    assert(c.get() == thread_count * kPerThread);
}
 
void test_concurrency_matrix() {
    constexpr int cases[] = {1, 2, 4, 8, 16};
    for (int thread_count : cases) run_counter_case(thread_count);
}

线程数矩阵至少覆盖顺序基线、低并发、接近机器并行度和适度过度订阅；生产上限应由测试配置补入，而不是硬编码“64 一定够压”。这个计数器例子只检查一个最终不变量；测试队列时还要记录每次 push/pop 的调用与返回历史，验证无重复、无丢失以及是否存在合法顺序解释。

容易踩的坑

小结

• 先按契约分类：竞态是时序相关的错误；数据竞争有精确定义且导致 UB；死锁是等待环无进展，活锁是持续执行却无高层进展；不变量破坏还要追到具体协议
• 现场证据不能只看 CPU：设置超时，保存全线程栈、等待图、重试与完成计数；CPU 使用率只能帮助提出假设
• TSan 是动态数据竞争检测器：它分析本次执行且被插桩的访问，零报告不是正确性证明，也不覆盖所有死锁、活锁和原子协议错误
• 并发测试要可判定、可重放：顺序参考模型、屏障、线程数矩阵、随机种子、操作历史、不变量和进展断言共同构成证据链
• 正确性与性能分开测：消毒器构建找缺陷，发布构建测吞吐、尾延迟和扩展曲线；测试通过不能证明所有调度，基准变快也不能证明协议正确