threadsanitizer（tsan）是linux下唯一能在运行时精准定位指令级数据竞争的工业级方案，通过影子内存和线程状态跟踪识别多线程对同一地址的非同步访问序列。
直接用 ThreadSanitizer（TSan）——它不是“辅助工具”，而是目前 Linux 下唯一能在运行时精准定位指令级竞争（如 counter++ 中读-改-写三步交错）的工业级方案。
为什么不用 GDB 或 perf 看汇编来查竞争
因为竞争不是某条指令出错，而是**多线程对同一内存地址的非同步访问序列**。GDB 单步只能看到一个线程的执行流；perf record -e cycles,instructions 只能统计热点，无法关联线程间内存访问时序。你看到的“两个线程都执行了 addl $1, (%rax)”，不等于发生了竞争——关键在于它们是否读到了彼此未写回的旧值。只有 TSan 这类带影子内存（shadow memory）和线程状态跟踪的工具，才能在运行时标记每次 load/store 的所属线程、锁状态、happens-before 关系。
如何用 ThreadSanitizer 编译并触发有效报告
必须同时满足以下条件，TSan 才会输出可操作的竞争位置：
- 编译时加
-fsanitize=thread -fno-omit-frame-pointer -g -O1：缺-fno-omit-frame-pointer会导致调用栈截断；-O1是 TSan 兼容的最高优化等级，-O2可能导致误报或漏报 - 链接时加
-pthread：否则std::thread构造可能绕过 TSan 的线程生命周期插桩 - 运行时不设
LD_PRELOAD或其他干扰内存分配的库：TSan 自带自己的 malloc wrapper，冲突会导致崩溃而非报告 - 确保竞争实际发生：单次运行没触发？用
for i in {1..10}; do ./a.out; done | grep -A10 "data race"多试几次
看懂 TSan 报告里的关键字段
一份典型报告里真正要盯住的只有三行：
-
WARNING: ThreadSanitizer: data race后面紧跟着的Location is heap block of size N allocated by thread T1 at ...——说明竞争对象是堆内存，且首次分配在线程 T1 -
Previous write of size 4 at 0x... by thread T2——T2 线程上次写这个地址的位置（文件+行号），这是第一个冲突点 -
Current read of size 4 at 0x... by thread T1——T1 线程当前读这个地址的位置，这是第二个冲突点；两行合起来就是“T2 写完还没刷到主存，T1 就读了旧值”
注意：如果报告里出现 mutex (0x...) acquired here，说明你用了锁但没 cover 住全部访问路径——比如忘了保护某个 getter 函数里的读操作。
TSan 报告为空但行为异常？检查这三点
不是所有并发问题都是数据竞争：
- 死锁：TSan 不报死锁，改用
gdb attach $PID→info threads→thread apply all bt看所有线程是否卡在pthread_mutex_lock - 原子性缺失但无竞争：比如用
std::atomic<int></int>但错误用了memory_order_relaxed导致可见性失效，TSan 认为“有同步”所以不报，需靠逻辑审查或memory_order_seq_cst临时替换验证 - 伪共享（false sharing）：多个线程高频修改同一 cache line 上不同变量，性能暴跌但 TSan 完全沉默，得用
perf stat -e cache-misses,cache-references结合perf record -e mem-loads,mem-stores定位
指令级竞争的本质，是 CPU 指令执行顺序与内存可见性之间的缝隙。TSan 填的是这个缝隙，但它填不了设计漏洞——比如你用 10 把互斥锁保护一个结构体的 10 个字段，却在业务逻辑里跨锁做原子性假设，TSan 依然会沉默。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
