用 -fsanitize=thread、-g 和 -pthread 编译可稳定捕获数据竞态；缺 -fno-omit-frame-pointer 会导致堆栈丢失关键行号，影响定位。
直接上结论：用 -fsanitize=thread 编译，配合 -g 和 -pthread，就能让 ThreadSanitizer（TSan）稳定捕获数据竞态；不加 -fno-omit-frame-pointer 可能导致堆栈丢失关键行号，这是最常被忽略的细节。
编译时必须加的三个选项
TSan 不是独立工具，而是靠编译器插桩实现的，缺一不可：
-
-fsanitize=thread：核心开关，启用 TSan 运行时监控逻辑 -
-g：生成调试符号，否则报告里只有地址、没有源码行号 -
-pthread：链接线程库，否则std::thread构造可能失败，TSan 也无法挂钩线程生命周期
漏掉任意一个，要么报错，要么静默失效。比如只加 -fsanitize=thread 不加 -pthread，程序可能在 std::thread 构造时崩溃，根本跑不到竞态触发点。
为什么一定要加 -fno-omit-frame-pointer
Clang/GCC 默认在优化级别 ≥-O2 时省略帧指针（frame pointer），这会导致 TSan 报告中的调用栈缺失中间几层，甚至只显示 _M_run 这类模板内部函数，找不到你写的 worker() 函数位置。
解决方案很简单：
- 开发/调试阶段统一用
-O1或-O0+-fno-omit-frame-pointer - 不要用
-O2或更高优化等级跑 TSan，它既拖慢速度，又削弱报告精度
实测中，没加这个选项的报告经常卡在 std::thread::_State_impl::_M_run，而加了之后能清晰看到 increment() example.cpp:9。
运行时报错但没输出竞争报告？检查这几个点
TSan 检测到问题时会打印带 WARNING: ThreadSanitizer: data race 的块状报告，如果只看到段错误或空屏，大概率是环境或配置问题：
- 确认系统有 TSan 运行时库：
ldconfig -p | grep tsan，缺少需重装 GCC/Clang（≥4.8） - 检查是否误用了
LD_PRELOAD或其他 sanitizer（如 ASan），TSan 不能和其他 sanitizer 同时启用 - 确保程序确实发生了并发访问：单线程跑不会触发任何 TSan 警告，哪怕代码里有竞态隐患
- 注意
std::atomic变量不会被 TSan 标记为竞态——它只报“未同步的普通内存访问”，这点常被误认为“没检测到”
报告里看到 “Previous write by thread T2” 却找不到对应代码？
TSan 报告中的 “Previous write” 行往往对应更早发生的竞态访问，但它不一定出现在你预期的位置。这是因为：
- 竞态是两个（或多个）访问的时间差问题，TSan 只记录它观测到的最近一对冲突操作
- 如果某个线程在循环里高频修改变量（如
counter++），TSan 可能只报告最后一次冲突，而前 99 次已覆盖过去 - 报告里的文件行号是访问发生点，不是声明点；若变量在头文件声明、多个 cpp 文件定义，要逐个检查所有写入位置
真正关键的是报告末尾的 Location is global 'counter' of size 4 —— 它锁定了问题变量名，顺着这个名全局搜索所有读写点，比死盯堆栈更高效。
TSan 不会告诉你“怎么修”，只会明确指出“哪里没同步”。修复本身（加 std::mutex、换 std::atomic、还是重构共享逻辑）得靠你判断——而这恰恰是最容易被跳过的一步：看到报告就去改代码，却没想清楚这个变量是否真该跨线程共享。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
