ThreadSanitizer（TSan）通过运行时动态追踪检测C++数据竞争，需编译链接均启用-fsanitize=thread，配合合理配置与调试可高效定位线程安全问题。

用 ThreadSanitizer（TSan）检测 C++ 线程安全问题，核心就两点：编译时加 -fsanitize=thread，运行时避免误报和漏报。 它不是静态分析工具，而是在程序运行时动态追踪内存访问和线程同步操作，自动发现数据竞争（data race）——这是最常见也最危险的线程安全问题。

编译与链接必须统一启用 TSan

TSan 需要整个程序（包括所有源文件、依赖的静态库）都用相同 sanitizer 编译，否则会漏检或崩溃。

• 所有 .cpp 文件编译时加：-fsanitize=thread -g -O2（-g 保留调试信息，-O2 可接受，TSan 在优化后仍有效）
• 链接时也要加：-fsanitize=thread，否则链接失败或行为未定义
• 禁用内联优化（如 -fno-inline）不是必须，但有助于定位竞争位置；实际项目中建议先用默认 -O2 测试
• 不要混用 TSan 和 ASan/UBSan，除非明确支持组合（如 -fsanitize=thread,address 在较新 Clang 中可行，但会显著变慢且需谨慎验证）

识别典型 TSan 报告内容

TSan 运行时一旦发现数据竞争，会打印类似下面的报告：

关键看三部分：读写线程和栈帧（确认哪两个线程在操作同一地址）、内存地址和变量名（定位共享变量）、调用链（找到未加锁的访问点）。注意“Previous”不一定是时间上最早的操作，而是 TSan 记录到的最近一次有冲突可能的访问。

减少误报和规避常见陷阱

• 全局/静态对象构造期间的访问：TSan 对 main() 之前的行为监控有限，尽量避免在全局对象初始化中启动线程或访问跨线程共享状态
• 故意的数据竞争（极少见）：如 lock-free 算法中的原子操作，必须用 std::atomic 显式声明，TSan 会自动忽略其非竞争性访问；切勿用 volatile 或裸指针模拟原子操作
• 使用 std::mutex、std::shared_mutex 或 std::atomic 后仍报竞争？检查是否：锁对象本身被多线程并发修改（比如多个线程 delete 同一把 mutex）、锁范围没覆盖全部临界区、用了不同 mutex 保护同一变量
• 第三方库未编译进 TSan？用 -fsanitize=thread 重新编译它，或临时用 TSAN_OPTIONS="ignore_noninstrumented_modules=1"（仅用于调试，会降低检测能力）

集成到日常开发流程

• CI 中加一条 TSan 构建+测试任务：用小规模并发测试用例快速触发竞争，不追求全覆盖，重在暴露明显问题
• 开发机上可配合 TSAN_OPTIONS="halt_on_error=1" 让程序在首次竞争时中断，方便 gdb 调试
• 对性能敏感模块，可在 debug 构建中启用 TSan，发布构建关闭；但上线前务必用 TSan 跑过核心并发路径
• 注意 TSan 会使程序变慢 5–15 倍、内存占用翻倍，不适合压测，只用于功能正确性验证

基本上就这些。TSan 不是银弹，但它能抓住绝大多数隐蔽的数据竞争——只要代码跑起来、线程动起来，它就能说话。别等线上 core dump 再查，把 TSan 当成和编译器警告一样自然的环节。