ThreadSanitizer（TSan）是Clang和GCC支持的实用数据竞争检测工具，启用只需编译选项如-fsanitize=thread，能自动暴露偶发崩溃、结果不一致等典型竞态问题，但仅限开发测试使用。
用 ThreadSanitizer 一跑就暴露竞争点
Clang 和 GCC 都支持 ThreadSanitizer（TSan），它是目前最实用的运行时数据竞争检测工具。加个编译选项就能启用，不需要改代码，也不依赖你“猜”哪几行可能出问题。
常见错误现象：程序偶发崩溃、结果不一致、某个变量值“莫名其妙”变掉，但单线程下永远复现不了——这大概率就是 TSan 要抓的典型竞争。
- Clang 下编译：
clang++ -fsanitize=thread -g -O2 main.cpp - GCC（≥9.1）下：
g++ -fsanitize=thread -g -O2 main.cpp - 必须带
-g，否则报错位置只显示汇编行；-O2可以保留，TSan 在优化后仍能工作 - 运行时报出类似
WARNING: ThreadSanitizer: data race的信息，会明确标出两个冲突访问的栈帧和内存地址
注意：TSan 会显著拖慢运行速度（5–10 倍）、增加内存占用，**只用于开发和测试阶段**，别打包进生产环境。
std::atomic 不是万能锁，得看访问模式
很多人以为只要把共享变量改成 std::atomic 就安全了，其实不然。原子性只保证单次读/写不被撕裂，但不解决逻辑上的竞态——比如“读-改-写”这种操作，std::atomic 默认的 memory_order_relaxed 无法阻止重排，也保不住复合语义。
立即学习“C++免费学习笔记（深入）”；
使用场景：计数器、标志位、状态切换这类简单用途可以放心用；但涉及条件判断再修改（如“如果 flag 为 false，则设为 true 并执行某操作”），就必须用 compare_exchange_weak 或加锁。
- 错误写法：
if (counter.load() —— 中间可能被其他线程插进来改掉 <code>counter - 正确写法（无锁）：
int expected = counter.load(); while (expected - 更清晰的做法：直接用
std::mutex包住整个判断+修改块，尤其当逻辑不止一行时
忘记 join() 或 detach() 会导致未定义行为
这是新手高频踩坑点：创建了 std::thread 对象，但没在析构前调用 join() 或 detach()，程序退出时该线程还在跑，或者已结束但资源未回收，极易引发内存访问违规或静默数据污染。
现象：程序有时 crash 在 std::thread::~thread()，报错信息类似 terminate called without an active exception；或者 TSan 报出“unjoined thread accessing shared data”类警告。
- 原则：每个
std::thread对象生命周期内，必须且只能调用一次join()或detach() - 推荐封装成 RAII 类型，比如用
std::jthread（C++20），它在析构时自动join() - 若确实需要后台线程长期运行且不等待，确保
detach()后不再访问该对象，也不要假设它一定存活
调试时别只盯着临界区，检查线程局部存储误用
有些问题看似是数据竞争，实则是误用了线程局部变量。比如用 thread_local 声明了一个指针，本意是每个线程独享一份缓存，但忘了初始化，导致多个线程共用同一块堆内存；或者在 lambda 捕获中隐式引用了外部变量，而该变量实际是全局或静态的。
容易被忽略的地方：lambda 默认按值捕获时，捕获的是副本；但若捕获的是指针或引用，就可能间接引入共享。
- 检查所有
thread_local变量是否都做了显式初始化（尤其是指针类型） - 避免在多线程中传递裸指针或引用到非线程安全对象；优先用
std::shared_ptr配合std::atomic控制所有权转移 - 用 TSan 运行时，它也能检测出对
thread_local变量的非法跨线程访问（虽然语义上不该发生，但编译器或手误可能导致）
真正难排查的不是“哪里加锁”，而是“哪些变量本不该共享却共享了”。TSan 能指出地址，但得你自己顺藤摸瓜看清楚那个地址到底是谁分配、谁持有、谁释放。
