helgrind 要准确检测 c 多线程竞态，必须编译时加 -g -o0 -pthread 且运行时用 valgrind --tool=helgrind；否则易漏报、误报或静默失败，修复后须重验零警告。
Helgrind 能直接报告 C 多线程程序里未同步的共享访问，但前提是编译和运行方式必须严格匹配它的分析逻辑——错一个参数，它就可能完全沉默，或者报一堆假阳性。
编译时必须加 -g -O0 -pthread
Helgrind 依赖调试符号定位源码行，也依赖未优化的指令顺序还原真实内存访问路径。如果用 -O2 编译，counter++ 可能被内联、合并甚至消除，Helgrind 就看不到竞争点了。
-
-g：提供行号和变量名，否则报错只显示地址，没法定位到counter或increment() -
-O0：禁用优化。哪怕只是-O1，都可能导致 Helgrind 漏报数据竞争 -
-pthread：不只是链接选项，它还影响 glibc 的线程行为（比如pthread_mutex_t初始化），缺了会触发 Helgrind 对锁状态的误判
运行时用 valgrind --tool=helgrind 启动，别跳过 --tool
Valgrind 默认走 memcheck，对多线程问题完全不敏感。漏写 --tool=helgrind 是最常见误操作——程序照常跑完，零输出，你以为没问题，其实竞态还在。
- 正确命令：
valgrind --tool=helgrind ./a.out - 错误命令：
valgrind ./a.out（默认 memcheck，不查线程）或valgrind --helgrind ./a.out（参数名错，会报 unknown option） - 如果程序很快退出，Helgrind 可能来不及输出报告，加
--time-stamp=yes或在末尾加sleep(1)确保日志刷出
看懂典型报错：重点盯 Possible data race 和 Locks held: none
Helgrind 不会说“你错了”，而是描述现场：“这里读，那里写，没锁”。关键信息藏在两行里：
-
Possible data race during read/write后面跟着的地址，要结合-g编译后的源码行反查是哪个变量（比如shared_variable） -
Locks held: none出现在访问上下文里，说明这次读/写确实没持任何锁——不是锁没生效，是根本没用 - 注意它不报死锁。如果你看到
lock order inversion提示，那只是潜在风险，不代表当前一定卡住
修复后必须重新跑 Helgrind，不能只信结果值
像 shared_variable 最终输出 20000 这种“看似正确”的结果，恰恰是最危险的信号。竞态是概率性的，一次运行不出错 ≠ 没问题。
- 加锁修复后，必须再跑一遍
valgrind --tool=helgrind ./a.out，确认零警告 - 如果仍报竞争，检查是否锁粒度太粗（比如整个循环加一把锁，性能差但安全），或更可能是锁对象没共享（比如每个线程自己 new 一个
pthread_mutex_t） - Helgrind 对
std::atomic支持有限，C 程序里优先用pthread_mutex_t+pthread_mutex_lock/unlock，别依赖原子操作“蒙混过关”
Helgrind 的真正价值不在“发现 bug”，而在“证明没有竞态”——但它只认你喂给它的那一套编译+运行流程。少一个 -g，它就变瞎；漏一次重验，你就可能把竞态带进生产环境。
