数据竞争（data race）是多线程中无同步并发读写同一内存位置导致的问题；strace/pstack无法检测，因它们不跟踪内存访问逻辑；唯一高效方法是用threadsanitizer编译运行，通过插桩监控读写并精确定位冲突。
信号竞争（signal race）在 Linux C++ 多线程程序中不是标准术语——真正要查的是 data race（数据竞争），即多个线程无同步地并发读写同一内存位置。信号（SIGUSR1 等）本身不“竞争”，但用信号触发的共享变量修改（如 std::atomic<int></int> 或裸 int）若没正确同步，就会引发数据竞争。
为什么 strace / pstack 不能查数据竞争
很多人一遇到多线程行为异常，就下意识用 strace -p 或 pstack，但这俩工具完全不感知内存访问逻辑：strace 只跟踪系统调用和信号传递事件（比如看到 sigreturn，但看不到信号处理函数里改了哪个变量）；pstack 只输出当前各线程的调用栈快照，无法关联到变量修改时序。它们对定位 data race 毫无帮助。
-
strace能告诉你“进程收到了 SIGUSR1”，但不能告诉你处理函数里是否对非原子全局变量做了非同步写入 -
pstack可能显示两个线程都卡在signalHandler里，但看不出它们是否同时读写了同一个int timeout - 真正需要的是能插桩内存访问、记录线程间读写依赖关系的工具
必须用 ThreadSanitizer 编译并运行
检测数据竞争唯一高效且可靠的方式，是用 ThreadSanitizer（TSan）重新编译运行。它通过编译期插桩，在运行时监控每一块内存的每次读写，并记录所属线程与堆栈，一旦发现两个线程在无同步前提下访问同一地址（其中至少一次是写），立刻报 WARNING: ThreadSanitizer: data race。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 编译命令必须带
-fsanitize=thread -fno-omit-frame-pointer -g -O1，缺一不可：-O2+会内联或优化掉访问，导致漏报 - 链接时需显式加
-pthread，否则 TSan 的线程拦截机制失效 - 运行时报错会精确到文件行号、涉及变量名（如
global 'timeout'）、两个冲突线程的完整调用栈 - 注意：TSan 会显著拖慢运行速度（10–20 倍），只用于调试，不可上线
Valgrind Helgrind 作为备选但有硬限制
如果因环境限制无法用 TSan（比如旧版 GCC valgrind --tool=helgrind，但它比 TSan 更脆弱：
- 仅支持基于
pthread的线程创建，C++11std::thread在 Linux 底层虽用 pthread 实现，但某些封装（如std::async）可能绕过 helgrind 监控点 - 不报告纯数据竞争，只报“锁序不一致”或“未加锁的条件变量使用”，对裸变量竞争（如直接改
int timeout）常常静默 - 要求程序以
SIGINT（Ctrl+C）退出，kill -9会导致 helgrind 无法生成报告 - 输出信息远不如 TSan 清晰，常需人工对照堆栈猜哪两行在争
信号处理函数里最容易踩的坑
很多开发者以为用了 sigaction 就安全了，其实信号处理函数内部的代码仍受多线程规则约束：
- 若处理函数修改的是非原子类型（如普通
int timeout），且业务线程也在读这个变量，就必须加锁或改用std::atomic -
std::atomic不是万能的：若用timeout.store(100, std::memory_order_relaxed)，虽避免崩溃，但业务线程可能因内存重排读到过期值；应优先用std::memory_order_seq_cst - 信号处理函数中禁止调用非异步信号安全函数（如
printf、malloc），但std::atomic操作是安全的 - 别在信号处理函数里加
std::mutex——pthread_mutex_lock不是异步信号安全的，会导致死锁
最常被忽略的一点：数据竞争不是“偶尔出错”，而是未定义行为（UB）。TSan 报告的那行代码，可能在你加日志后就不再复现——不是问题修好了，是 UB 的表现形式变了。必须按报告逐行修复，不能靠“试几次没崩就不管”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
