第27章测试与验证

课程目录第27章测试与验证

27、测试与验证：多线程程序的测试策略、压力测试工具、使用ThreadSanitizer检测数据竞争

多线程程序的测试，说实话，比单线程难了不止一个量级。单线程程序你跑一遍对了，大概率就对了。多线程呢？跑一千遍对了，第一千零一遍可能就崩了。我在项目中遇到过太多次这种“幽灵bug”——本地怎么测都过，上了生产环境就随机崩溃。

为什么会这样？因为多线程的bug往往是时序相关的。你无法控制线程调度顺序，所以测试必须覆盖各种可能的交错执行路径。今天我们就聊聊怎么系统性地搞定这件事。

多线程测试的核心难点

先说说多线程测试为什么这么头疼。我总结了三个核心问题：

非确定性：同样的输入，每次执行结果可能不同。你没法像单线程那样“复现”bug。
时序敏感：bug往往只在特定线程交错顺序下才出现。跑一万次可能只触发一次。
状态爆炸：N个线程、M个共享变量，可能的交错路径是天文数字。

嗯，这里要注意：多线程测试不是为了证明程序没有bug，而是为了尽可能暴露潜在的竞态条件。你想想看，如果测试跑了一万次都没问题，你只能说“在这个测试环境下没发现bug”，不能说“程序是安全的”。

测试策略：分层打怪

我个人习惯把多线程测试分成四个层次，从低到高逐步推进：

层次	测试类型	目标	工具/方法
L1	单元测试	验证单个同步原语正确性	Google Test, Catch2
L2	并发单元测试	验证小规模并发场景	std::thread + 断言
L3	压力测试	暴露竞态条件和死锁	自定义压测框架
L4	动态分析	检测数据竞争和死锁	ThreadSanitizer, Helgrind

L1：单元测试

先确保每个锁、每个条件变量、每个原子操作本身是没问题的。比如你封装了一个自旋锁，先单线程测它的基本功能：加锁、解锁、重入等。这一步没什么特别的，就是常规单元测试。

L2：并发单元测试

这一步开始引入多线程。我通常的做法是：创建2-4个线程，让它们同时操作同一个共享资源，然后验证最终结果是否符合预期。

// 并发单元测试示例：测试线程安全的计数器
#include <gtest/gtest.h>
#include <thread>
#include <vector>
#include "ThreadSafeCounter.h"

TEST(ThreadSafeCounterTest, ConcurrentIncrement) {
    ThreadSafeCounter counter;
    const int NUM_THREADS = 4;
    const int INCREMENTS_PER_THREAD = 10000;
    
    std::vector<std::thread> threads;
    for (int i = 0; i < NUM_THREADS; ++i) {
        threads.emplace_back([&counter]() {
            for (int j = 0; j < INCREMENTS_PER_THREAD; ++j) {
                counter.increment();
            }
        });
    }
    
    for (auto& t : threads) {
        t.join();
    }
    
    EXPECT_EQ(counter.get(), NUM_THREADS * INCREMENTS_PER_THREAD);
}

这段代码看着简单，但有个坑：如果计数器不是线程安全的，这个测试大概率会失败。我曾经在一个项目里就因为这个测试没通过，才发现有人用了普通的int而不是std::atomic。

L3：压力测试

压力测试说白了就是“往死里跑”。把线程数加到几十上百，把操作次数加到百万级，看看会不会出问题。

我的经验：压力测试一定要在Release模式下跑。Debug模式下编译器可能插入额外的检查，反而掩盖了竞态条件。另外，最好在性能较差的机器上跑——线程切换越频繁，越容易暴露问题。

// 压力测试框架示例
#include <iostream>
#include <thread>
#include <vector>
#include <atomic>
#include <chrono>

class StressTester {
public:
    StressTester(int num_threads, int duration_seconds)
        : num_threads_(num_threads)
        , duration_seconds_(duration_seconds)
        , stop_flag_(false) {}
    
    template<typename Func>
    void run(Func&& workload) {
        std::vector<std::thread> threads;
        for (int i = 0; i < num_threads_; ++i) {
            threads.emplace_back([this, &workload]() {
                while (!stop_flag_.load(std::memory_order_relaxed)) {
                    workload();
                }
            });
        }
        
        std::this_thread::sleep_for(std::chrono::seconds(duration_seconds_));
        stop_flag_.store(true, std::memory_order_relaxed);
        
        for (auto& t : threads) {
            t.join();
        }
    }
    
private:
    int num_threads_;
    int duration_seconds_;
    std::atomic<bool> stop_flag_;
};

// 使用示例
int main() {
    StressTester tester(8, 30);  // 8个线程跑30秒
    tester.run([]() {
        // 这里放你的并发操作
    });
    return 0;
}

L4：动态分析——ThreadSanitizer

这是我最想强调的部分。ThreadSanitizer（简称TSan）是Google开发的动态数据竞争检测工具，集成在Clang和GCC中。它能在运行时检测未加锁的共享内存访问。

  核心原理：TSan在编译时插入检测代码，记录每次内存访问的线程ID和调用栈。如果检测到两个线程同时访问同一内存位置，且至少一个是写操作，并且没有同步机制保护，就报告数据竞争。

使用方式很简单，编译时加上 -fsanitize=thread -g -O1 即可：

// 编译命令
g++ -fsanitize=thread -g -O1 -o test_program test.cpp -lpthread

// 运行
./test_program

来看一个实际例子。假设我们有段代码存在数据竞争：

#include <thread>
#include <iostream>

int shared_data = 0;  // 没有用原子操作或互斥锁

void writer() {
    for (int i = 0; i < 100000; ++i) {
        shared_data++;  // 写操作
    }
}

void reader() {
    for (int i = 0; i < 100000; ++i) {
        int val = shared_data;  // 读操作，没有同步
        (void)val;
    }
}

int main() {
    std::thread t1(writer);
    std::thread t2(reader);
    t1.join();
    t2.join();
    std::cout << "Final value: " << shared_data << std::endl;
    return 0;
}

用TSan运行后，会输出类似这样的报告：

==================
WARNING: ThreadSanitizer: data race (pid=12345)
  Write of size 4 at 0x7f1234567890 by thread T1:
    #0 writer() test.cpp:8

  Previous read of size 4 at 0x7f1234567890 by thread T2:
    #0 reader() test.cpp:13

  Location is global 'shared_data' of size 4 at 0x7f1234567890

  Thread T1 (tid=12346, running) created by main at:
    #0 main test.cpp:19

  Thread T2 (tid=12347, running) created by main at:
    #0 main test.cpp:20
==================

这个报告非常清晰：告诉你哪个线程在写、哪个线程在读、具体在哪一行、变量是什么。修复方法也很简单——给shared_data加上std::atomic，或者用互斥锁保护。

注意：TSan有性能开销，运行速度会慢2-5倍，内存占用也会增加。所以一般只在测试阶段使用，不要在生产环境开启。另外，TSan只能检测运行时实际发生的竞争，不能保证覆盖所有可能的交错路径。

SVG：多线程测试与验证知识体系

避坑指南

最后分享几个我踩过的坑：

不要依赖sleep来同步线程。我曾经用sleep(1)来“确保”某个线程先执行完，结果换台机器就崩了。正确的做法是用条件变量或屏障。
压力测试要随机化。固定模式的测试容易漏掉边界情况。我习惯在压测中随机插入短sleep，模拟真实世界的线程调度不确定性。
TSan不是银弹。它只能检测数据竞争，检测不了死锁、活锁、优先级反转等问题。死锁检测可以用Helgrind（Valgrind工具集的一部分）。
记录复现步骤。多线程bug最难的是复现。我建议在测试代码中加入日志，记录每次操作的线程ID和时间戳，方便事后分析。

我的习惯：每次提交代码前，先用TSan跑一遍单元测试和压力测试。虽然慢了点，但能拦截90%以上的数据竞争问题。这比上线后出问题再排查划算多了。

好了，多线程测试就聊到这里。记住：测试不是万能的，但不测试是万万不能的。尤其是多线程程序，再怎么小心都不为过。

📚 课程目录

27、测试与验证：多线程程序的测试策略、压力测试工具、使用ThreadSanitizer检测数据竞争

多线程测试的核心难点

测试策略：分层打怪

L1：单元测试

L2：并发单元测试

L3：压力测试

L4：动态分析——ThreadSanitizer

SVG：多线程测试与验证知识体系

避坑指南