ThreadSanitizer能精准定位多线程数据竞争：它在运行时捕获哪两个线程、在哪一行代码、对哪个变量发生读写冲突，需用-g -O1 -fsanitize=thread编译，所有目标文件须统一启用，报告中的双调用栈即真实冲突路径。
用 ThreadSanitizer 直接捕获数据竞争点
非线程安全函数引发的问题（比如 std::cout、malloc、自定义全局计数器）在并发访问时大概率触发数据竞争，而 TSan 能在运行时精准定位读写冲突的变量、线程 ID 和调用栈。它不是猜测工具，是能告诉你“哪两个线程、在哪一行、对哪个变量、以什么方式冲突”的检测器。
编译时加参数启用：
g++ -fsanitize=thread -fno-omit-frame-pointer -g -O1 main.cpp -o main
关键点：
-
-O1是必须的——优化太高会内联或重排，TSan 检测失效；太低则影响插桩精度 - 所有参与链接的目标文件（.o）都得用相同 TSan 选项编译，否则漏检
- 运行时报出的 “Data race on address …” 后面跟着的两个调用栈，就是真实冲突路径，不用再猜
看日志乱序不等于执行乱序：先锁住输出再判断
很多开发者看到控制台输出顺序错乱（比如线程 2 的日志出现在线程 1 前面），就断定“线程执行顺序不对”，其实只是 std::cout 本身非线程安全，缓冲区被交叉写入。这会掩盖真实问题，甚至误导你去加 sleep_for 这种不可靠手段。
立即学习“C++免费学习笔记（深入）”；
验证真实执行顺序的最小改动：
- 把所有关键日志包裹进
std::mutex+std::lock_guard - 每条日志开头加上
std::this_thread::get_id()和std::chrono::steady_clock::now().time_since_epoch().count() - 改完再跑，如果输出仍乱序，说明真有调度/同步问题；如果变有序，那之前只是输出污染
查非线程安全函数调用链：从崩溃点反推共享访问路径
当程序崩溃（如 SIGSEGV 或 abort）且堆栈里出现 malloc、free、printf、std::string::assign 等函数时，极可能源于多个线程同时操作同一内存块或静态缓冲区。这时候不能只盯崩溃行，要顺着调用栈往上找“谁传了什么指针进来”。
GDB 中快速定位共享访问源头：
- 崩溃后执行
info threads，确认哪些线程还活着、哪些已卡住 - 对每个可疑线程执行
f 3（切换到上三层栈帧），看是否都在操作同一个全局对象或静态变量 - 用
p &shared_var查地址，再用info proc mappings确认该地址是否落在 .data 或 .bss 段——如果是，基本坐实多线程无保护访问
单例初始化里的竞态窗口最常被忽略
C++ 中手写单例（尤其是 C 风格的 static void* instance = nullptr + 双检锁）是高频雷区。问题不在“用了非线程安全函数”，而在“检查和赋值之间存在可被抢占的窗口”。哪怕你用的是 pthread_mutex_lock，若第二次 if (instance == nullptr) 没放在锁内，照样崩。
典型错误模式：
if (instance == nullptr) {
pthread_mutex_lock(&lock);
// ❌ 缺少二次检查！这里可能已有其他线程完成赋值
instance = malloc(...);
pthread_mutex_unlock(&lock);
}真正安全的做法只有两种：
- 用
std::call_once+std::once_flag（C++11 起标准方案，无竞态、无锁开销） - 若必须手写双检锁，第二层
if必须在锁内，且锁对象生命周期要覆盖整个初始化过程
这类问题往往只在高并发压测时暴露，静态分析工具也难覆盖——它不报数据竞争，但会导致重复初始化、资源泄漏或野指针。
