数据竞态的最小触发条件是:共享变量、至少一个写操作、无同步机制。三者缺一不可,且不要求严格时间上的同时发生,指令重排或缓存不一致即可引发。
数据竞态发生在两个或更多线程**同时访问同一块内存地址**,且其中至少一个访问是写操作,**又没有任何同步机制(如互斥锁、原子操作、内存屏障)约束访问顺序**时。它不要求“同时发生”在严格时间意义上,只要编译器或 CPU 可能重排指令、缓存不一致、或线程调度导致读写交错,就构成竞态。
共享变量 + 至少一个写操作 + 无同步
std::vector 的 size() 返回值被多个线程读),而其内部状态未受保护,也可能因结构体字段未原子更新引发间接竞态volatile 关键字不能防止数据竞态——它只禁用编译器优化,不影响 CPU 指令重排,也不提供原子性或同步语义看变量是否跨线程共享,再看有没有任何同步原语包裹对它的读写。以下模式几乎必然竞态:
#include#include int shared_counter = 0; // 全局非原子变量 void increment() { for (int i = 0; i < 100000; ++i) { ++shared_counter; // 非原子:读-改-写三步,可被中断 } } int main() { std::thread t1(increment); std::thread t2(increment); t1.join(); t2.join(); // shared_counter 极大概率 ≠ 200000 }
++shared_counter 展开为三条机器指令(load, add, store),任意时刻都可能被另一线程打断shared_counter += 1 或 shared_counter = shared_counter + 1,问题依旧std::atomic 替换后,++ 才成为原子操作;但要注意默认内存序是 std::memory_order_seq_cst,有性能代价,高竞争场景需评估是否可降级锁本身不能自动覆盖所有共享访问路径。常见疏漏包括:
std::mutex 保护了写,但另一个函数直接读了 shared_counter 且没锁mutex_a 和 mutex_b,卡死前可能已造成部分写入,重启后状态难复现lock()/unlock() 而非用 std::lock_guard,异常路径下可能漏解锁即使你写了看似“顺序”的代码,编译器优化和硬件执行模型仍可能制造竞态。例如:
立即学习“C++免费学习笔记(深入)”;
// 线程 A
flag = false;
data = 42;
flag = true; // 希望 data 写完再置 flag
// 线程 B
while (!flag) {} // 忙等
use(data); // 可能拿到未初始化的 data!
flag = true 提前到 data = 42 之前(无数据依赖时允许重排)flag 写入本地缓存而未刷到主存,B 线程读到旧值;即使读到新 flag,也可能因缓存未同步而读到旧 data
std::atomic + 显式内存序:flag.store(true, std::memory_order_release) 和 flag.load(std::memor
y_order_acquire)
std::atomic_thread_fence 是全局屏障,慎用;多数情况应优先用原子变量的成员函数指定序,而非裸 fenceThreadSanitizer(clang++ -fsanitize=thread)运行时抓取,或用 std::atomic_ref(C++20)临时包装已有变量做原子访问。