helgrind必须显式启用（--tool=helgrind），否则valgrind默认运行memcheck，对多线程竞态完全无感；编译需-g -o0 -pthread，输出重点关注“possible data race”“conflicts with previous write”和“lock at...was first acquired”三类提示。
helgrind 必须显式启用，否则完全不检测竞态
直接运行 valgrind ./your_program 不会发现任何数据竞争——memcheck 是默认工具，它对多线程读写冲突完全无感。真正起作用的是 helgrind，必须加 --tool=helgrind。漏掉这个参数，程序照跑，但所有竞态都静默放过。
常见错误包括：
- 误以为 valgrind 默认检查线程安全，结果上线后偶发崩溃才暴露问题
- 在 CI 脚本里只写
valgrind ./test，长期收不到竞态告警
编译时要关优化、带调试符号、显式链接 pthread
helgrind 依赖源码行号和未重排的指令流。-O2 以上优化可能把 shared_variable++ 拆成 load-modify-store 三步并重排，导致实际执行路径和源码逻辑不一致；没有 -g 就只能看到 0x4012ab 这类地址，无法定位到变量声明或访问点；缺 -pthread 会让 helgrind 无法识别 pthread_create，线程创建行为被当成黑盒，后续所有同步分析失效。
正确编译命令是：
gcc -g -O0 -pthread test.c -o test
注意：-pthread 不是可选的“建议”，而是 helgrind 正确建模线程生命周期的前提。
看懂 helgrind 输出里的三类关键提示
输出中真正要盯住的是这三行模式：
-
Possible data race during read或write：说明某个变量（如counter）被多个线程并发访问，且至少一次没锁保护 -
This conflicts with a previous write：给出另一处冲突访问的位置，通常跨线程、甚至跨函数调用栈 -
Lock at 0x... was first acquired here：如果用了锁，会指出首次加锁点，帮你确认锁是否覆盖了全部临界区
所有提示都附带完整调用栈，但要注意：它只报告实际执行到的路径。比如一个 if (flag) { shared_var++; } 分支没触发，里面的竞态就永远不会被发现——覆盖率决定检测边界。
共享变量读写是否构成竞态，取决于是否满足三个条件
helgrind 报警不是看“有没有读写”，而是看“有没有未受保护的并发写或读-写混合”。判断依据是：
- 多个线程同时访问同一内存地址（通过指针、全局变量或静态局部变量）
- 其中至少一次是写操作（纯并发读不报）
- 访问之间没有建立 happens-before 关系（即没用互斥锁、原子操作、条件变量或内存屏障同步）
典型误判场景：用 std::atomic<int></int> 读写不会触发报警；但若混用 atomic_load 和裸指针写入同一地址，helgrind 仍会报——它不理解 C++ 原子语义，只看底层内存访问指令流。
最常被忽略的一点：helgrind 的检测能力严格受限于程序运行时的实际线程调度路径。哪怕逻辑上存在竞态，只要某次运行中两个线程的临界区没真正交错，就不会触发报警。所以单次运行不能证伪，得结合多轮随机调度 + 覆盖率验证。
