threadsanitizer（tsan）是clang和gcc支持的动态分析工具，1. 通过编译时插桩（-fsanitize=thread -g）运行时监控内存访问；2. 能精准定位数据竞争，输出冲突线程、调用栈、读写顺序及源码行号；3. 仅用于调试，性能开销大（10–20倍），禁用高优化（-o1为宜）并须链接-pthread。
用 ThreadSanitizer 快速定位数据竞争
Clang 和 GCC 都支持 ThreadSanitizer（TSan），它是目前最实用、开箱即用的数据竞争检测工具。它不依赖源码注释或手动加锁标记，而是通过插桩运行时内存访问来动态发现未受保护的共享变量读写冲突。
编译时加上 -fsanitize=thread -g 即可启用（注意：必须同时开启调试信息，否则报错位置不准）：
g++ -fsanitize=thread -g -O1 -pthread main.cpp -o main
运行后一旦触发竞争，TSan 会直接打印出两个冲突线程的完整调用栈、变量地址、读/写类型，甚至标出哪一行是“先发生的”、哪一行“后发生但没同步”。这是唯一推荐作为第一排查手段的方式。
- 不要用
-O2或更高优化等级，TSan 在高优化下可能漏报或误报 - 务必链接
-pthread，否则 TSan 无法识别线程创建点 - TSan 会显著拖慢程序（10–20 倍），只用于调试，不可上线
为什么 gdb 单步进不了数据竞争现场
数据竞争本质是**非确定性时序问题**：两个线程对同一内存地址的访问缺少 happens-before 关系。你用 gdb 单步执行时，已经强行串行化了执行流，竞争条件被破坏，现象消失——这不是 gdb 不好，而是它根本不是为这种问题设计的。
常见错误做法是反复加 std::this_thread::sleep_for 或 std::cout 打点，试图“稳定复现”，结果只是把竞争延后或掩盖，还可能引入新的竞态（比如 std::cout 本身有内部锁）。
- 不要在怀疑竞争的代码段里插
std::cout或日志输出——它自带同步副作用，会干扰原始行为 - 避免用
gdb attach到已运行的多线程进程再设断点：线程状态已不可控，断点命中时机与原始竞争无关 - 如果必须用调试器，优先用
thread apply all bt查看所有线程当前栈，配合 TSan 报告交叉验证
std::atomic 和 mutex 不是万能解药
看到 TSan 报告某变量竞争，第一反应往往是“加个 std::atomic”或“套个 std::mutex”，但容易忽略语义是否匹配：
-
std::atomic只保证单操作原子性，不保证复合操作（如counter++是读-改-写三步）——要用fetch_add等显式原子操作 - 对结构体或对象整体加锁时，必须确保所有访问路径都走同一把
std::mutex，漏掉一个裸访问就会继续触发 TSan - 用
std::shared_mutex替代std::mutex时，要确认读写路径确实分离；否则读锁+写锁混用仍可能引发死锁或遗漏保护
更隐蔽的问题是“伪共享”（false sharing）：多个 std::atomic 变量紧挨着放在同一 cache line，导致 CPU 频繁无效化整行，性能暴跌——这时 TSan 不报错，但程序变慢且难以解释。
Valgrind 的 Helgrind 和 DRD 已基本淘汰
虽然 valgrind --tool=helgrind 曾是经典选择，但现在它的实用性大幅下降：
- 不支持 C++11
std::thread的部分底层实现（尤其在较新 glibc 上），常报“unhandled syscall”或直接崩溃 - 漏报率高，尤其对短生命周期线程或 lock-free 结构
- 运行比 TSan 还慢（50 倍以上），且堆栈信息常截断，定位困难
除非你被困在旧系统（如 CentOS 6 + GCC 4.4），否则别花时间配 Helgrind。TSan 在 Clang 3.2+/GCC 4.9+ 上稳定可用，覆盖所有现代 C++ 并发设施（std::async、std::promise、std::latch 等）。
真正麻烦的是那些 TSan 也抓不到的场景：比如跨进程共享内存、信号处理函数中修改全局变量、或使用自定义调度器绕过标准线程库——这些得靠静态分析工具（如 Clang Static Analyzer 配 concurrency checkers）或人工逐行审阅同步契约。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
