星期一, 24 8 月, 2026
Latest:
i007.cc

i007.cc

优先队列-降维打击

05.价值资料

讲讲volatile 和 atomic 的区别

Will

这道题是 NVIDIA 面试里拉开差距的题目，答对的人不多。很多人以为 volatile 是”弱化版的 atomic“，实际上两者解决的是完全不同的问题。

两者各自解决什么问题

volatile 解决的问题：防止编译器优化掉对某个内存位置的读写。

std::atomic 解决的问题：保证多线程并发访问共享变量时的正确性。

这两件事本质上不同，混用是 C++ 并发 bug 的高频来源。

volatile：只和编译器说话

volatile 告诉编译器：”这个变量的值可能被你看不到的力量改变，每次读都必须真正去内存里取，每次写都必须真正写回内存，不要优化。”

看一个经典例子：

cpp
// 场景：轮询一个硬件状态寄存器
int* status_reg = reinterpret_cast<int*>(0xDEAD0000);  // 内存映射 IO

// 不加 volatile：
while (*status_reg == 0) {}   // 编译器看到：这个值从没被修改过
                              // 优化后变成：if (*status_reg == 0) while(true) {}
                              // 只读一次，然后永远循环！

// 加 volatile：
volatile int* status_reg = reinterpret_cast<volatile int*>(0xDEAD0000);
while (*status_reg == 0) {}   // 编译器老老实实每次去内存读
                              // 因为它知道这个地址的值可能被硬件改变

 

volatile 的核心保证：对该变量的每次读写在编译后的汇编里都真实存在，不会被合并、删除、缓存到寄存器。

volatile 的边界：它只和编译器的优化行为有关，对 CPU 的乱序执行完全没有约束力。

std::atomic：同时和编译器、CPU 说话

多线程程序面临两层乱序：

源代码顺序
    ↓ 编译器可能重排（指令调度优化）
汇编指令顺序
    ↓ CPU 可能重排（乱序执行、Store Buffer、Cache）
实际执行顺序

 

volatile 只阻止第一层，std::atomic 两层都阻止，并且额外保证操作的原子性（不可分割）：

cpp
std::atomic<int> counter{0};

// 线程1
counter.fetch_add(1, std::memory_order_relaxed);

// 这一条指令在底层展开为：
// 1. 读 counter 的当前值
// 2. 加 1
// 3. 写回
// std::atomic 保证这三步对其他线程是不可分割的
// 不可能有另一个线程在步骤 1 和 3 之间插入，读到中间状态

 

为什么 volatile 在多线程里没有意义

用一个典型的错误来说明：

cpp
volatile bool ready = false;
int data = 0;

// 线程1（生产者）
void producer() {
    data  = 42;        // 步骤 A
    ready = true;      // 步骤 B
}

// 线程2（消费者）
void consumer() {
    while (!ready) {}  // 等待步骤 B
    std::cout << data; // 期望读到 42
}

 

看起来合理，实际上有三个问题：

问题一：编译器可以把 A 和 B 调换顺序。

volatile 阻止编译器对 ready 本身的优化，但不阻止它把 data = 42 移到 ready = true 之后——这两行操作的是不同的变量，编译器认为可以自由调度。

问题二：CPU 的 Store Buffer 可能让 B 对其他核可见，但 A 还没有。

现代 CPU 有写缓冲区，写操作不一定立刻对其他核可见。线程2 可能看到 ready = true，但 data 的写入还在线程1 的 Store Buffer 里，没有刷到共享内存。

问题三：volatile 本身不保证原子性。

在某些架构上，64 位写可能被拆成两次 32 位写。如果另一个线程恰好在中间读，会读到撕裂的值。

cpp
// 正确写法：
std::atomic<bool> ready{false};
int data = 0;

void producer() {
    data = 42;
    // memory_order_release：保证此行之前的所有写入，
    // 对看到 ready=true 的线程可见
    ready.store(true, std::memory_order_release);
}

void consumer() {
    // memory_order_acquire：保证此行之后的所有读取，
    // 能看到 store(release) 之前的所有写入
    while (!ready.load(std::memory_order_acquire)) {}
    std::cout << data;  // 保证读到 42
}

 

原子性的真实含义

volatile 的读写不保证原子性：

cpp
volatile long long v = 0;

// 在 32 位系统上，这一行可能编译为两条指令：
v = 0x0123456789ABCDEF;
// mov [v],   0x89ABCDEF   ← 低 32 位
// mov [v+4], 0x01234567   ← 高 32 位
// 另一个线程在两条指令之间读，会读到撕裂的值

std::atomic<long long> a{0};
a.store(0x0123456789ABCDEF);
// 编译为单条原子指令，或者带锁的操作，不可能被中间观察

 

什么时候需要同时用两者

这是少有人知道的场景：内存映射 IO 的寄存器被多个线程同时访问。

cpp
// 只用 volatile：多线程访问不安全（无原子性）
volatile int* hw_reg = (volatile int*)0xDEAD0000;

// 只用 atomic：编译器可能认为没有"外部修改"而优化掉某些读
std::atomic<int>* hw_reg = (std::atomic<int>*)0xDEAD0000;

// 正确做法：volatile + atomic（C++20 有 atomic_ref，更优雅）
// 或者用平台特定的内存屏障 + volatile
volatile std::atomic<int>* hw_reg = (volatile std::atomic<int>*)0xDEAD0000;

 

实际上这个场景在普通游戏后端开发里几乎遇不到，更多出现在驱动程序和嵌入式系统里——对 NVIDIA 面试来说是加分项。

一张表对比

volatile std::atomic
防止编译器优化/合并读写 ✅ ✅
防止 CPU 乱序执行 ❌ ✅
保证操作原子性 ❌ ✅
线程安全 ❌ ✅
适用于内存映射 IO ✅ ❌（可能被优化）
适用于多线程共享变量 ❌ ✅
运行时开销 无 有（内存屏障、原子指令）

面试里的一句话总结

volatile 解决的是”编译器把我的读写优化掉了”的问题，适用于硬件寄存器和信号处理；std::atomic 解决的是”多线程并发访问共享数据”的问题，同时提供原子性和内存序保证。两者针对的是完全不同的问题，在多线程场景里 volatile 不是 atomic 的替代品，它根本不提供任何线程安全保证。

发表回复