TSan需编译时启用-fsanitize=thread且限用-O1，依赖插桩追踪内存访问；禁用高优化以防漏报误报，报告通过冲突线程的读写位置定位未同步共享访问。
编译时必须加 -fsanitize=thread 且禁用优化
TSan 不是运行时加载的库，它靠编译器在插桩（instrument）读写内存的指令来追踪数据访问。不加 -fsanitize=thread 就完全没作用；加了但开了 -O2 或更高优化，TSan 可能漏报甚至误报——因为编译器会重排、合并、消除内存访问，导致插桩点和实际执行行为错位。
推荐的最小可行编译命令是：
g++ -g -O1 -fsanitize=thread -pthread main.cpp -o main
注意三点：
-
-O1是 TSan 官方文档明确推荐的最高安全优化等级 -
-pthread必须显式带上（即使你只用std::thread），否则链接会失败或检测失效 -
-g能让报告带源码行号，否则只能看到汇编地址
TSan 报告里看到 WARNING: ThreadSanitizer: data race 怎么定位
报告开头会标出两个冲突线程的操作位置，格式通常是「Thread T1 writes X at …」和「Thread T2 reads/writes X at …」。关键不是看哪一行报错，而是看两处访问是否共享了同一块未加同步的内存——比如两个线程同时读写同一个全局 int counter，或通过不同指针访问同一对象的成员。
常见误判场景：
- 只读共享数据（如 const 全局表）不会触发 TSan，除非有写操作混入
- 使用
std::atomic的变量默认不报，但若混用非原子访问（比如对std::atomic<int> a</int>用*reinterpret_cast<int>(&a)</int>直接读内存），TSan 会当成普通内存处理并报竞态 - 线程局部存储（
thread_local）变量天然隔离，TSan 不跟踪
std::mutex、std::shared_mutex 等）或顺序约束（std::memory_order）的情况下，访问了同一地址。
为什么加了 std::mutex 还报竞态
绝大多数情况是锁没真正保护到那块内存。典型原因：
- 锁对象本身是局部变量或不同实例（比如每个线程 new 一个
std::mutex），根本起不到互斥作用 - 访问变量前忘了
lock()，或者unlock()写在异常路径之外，导致部分执行流跳过加锁 - 用了
std::mutex但访问的是不同变量（比如锁 A，改的是变量 B），TSan 无法推断逻辑关联 - RAII 用法错误：比如
std::lock_guard作用域太小，只包住了赋值语句，而前后还有其他共享访问
std::lock_guard 或 std::unique_lock 作用域内，再跑 TSan。如果还报，大概率是变量地址被意外别名化（例如通过 void* 或引用逃逸）。
TSan 在 CI 或生产环境能用吗
不能。TSan 会让程序变慢 5–10 倍，内存开销翻倍以上，且仅支持 x86_64 和 aarch64。它设计目标就是开发和测试阶段的诊断工具，不是运行时防护机制。
更关键的是：TSan 是概率性检测器——它只捕获执行过程中实际发生的竞态，不保证全覆盖。一次没报不等于没 bug，尤其当竞态依赖特定调度顺序时。
所以正确做法是：
- 本地开发时用 TSan + 单元测试多线程用例反复跑
- CI 中固定开启 TSan 构建并运行关键并发测试（注意超时阈值要调高）
- 生产环境绝对不要带
-fsanitize=thread启动，也不要指望它兜底
std::mutex 或 std::atomic 并配以清晰注释说明保护范围。立即学习“C++免费学习笔记（深入）”；
