这3个volatile使用错误，正在毁掉你的多线程程序

写C/C++多线程程序，绕不开线程安全问题。很多程序员看到共享变量，第一反应是加个volatile关键字，以为这样就能保证线程安全了。

但这是错的。

volatile在多线程中根本不够用，它只能防止编译器优化，不能保证原子性，也不能保证内存序，用错了，程序看起来没问题，实际上随时可能崩，而且这种Bug特别难复现，往往在生产环境高并发时才暴露。

今天聊聊3个最常见的volatile使用错误。

错误1：用volatile做计数器

这是最常见的错误。很多人以为给计数器加个volatile，就能在多线程中安全使用。

看这段代码：

volatileintcounter=0;voidthread_func(){for(inti=0;i<100000;i++){counter++;// 看起来没问题？}}

看起来没问题，对吧？但这段代码在多线程环境下会出错。

为什么？因为counter++不是原子操作，它实际上是三步：从内存读取counter的值到寄存器，寄存器的值加1，把寄存器的值写回内存，而volatile只能保证每次都从内存读取、每次都写回内存、不会被编译器优化掉，但它不能保证这三步是原子的，两个线程可能同时读取、同时加1、同时写回，导致丢失更新。

两个线程同时执行counter++，可能发生这种情况：

线程A：读取counter=0 线程B：读取counter=0 线程A：计算0+1=1 线程B：计算0+1=1 线程A：写回counter=1 线程B：写回counter=1

两次加1，结果counter只增加了1，这就是数据竞争（data race），在高并发场景下，这种问题会导致计数严重不准，比如10000次加1操作，最后counter可能只有8000多，丢失了近2000次更新。

正确做法：用std::atomic

std::atomic<int>counter(0);voidthread_func(){for(inti=0;i<100000;i++){counter++;// 原子操作，线程安全}}

std::atomic保证了原子性，counter++会被编译成一条原子指令（比如x86的lock add），整个操作不可分割，不会被其他线程打断，CPU通过缓存一致性协议保证这条指令执行期间的原子性，从根本上杜绝了数据竞争。

错误2：用volatile保护共享数据结构

有些程序员以为volatile能保护复杂的数据结构。比如这样：

structSharedData{intx;inty;intz;};volatileSharedData data;voidthread1(){data.x=1;data.y=2;data.z=3;}voidthread2(){if(data.x==1&&data.y==2&&data.z==3){// 做点什么}}

这段代码有两个致命问题。

问题1：volatile不保证原子性

thread1的三次赋值不是原子的，thread2可能看到x=1, y=0, z=0这种中间状态，volatile不能把多个操作打包成原子操作，每个赋值都是独立的，线程切换可能发生在任何时候。

问题2：volatile不保证内存序

更要命的是，编译器和CPU可能会重排指令，thread1的三次赋值顺序可能变成先写z、再写x、最后写y，volatile不提供happens-before保证，它只保证每次访问都从内存读写，但不保证访问的顺序，thread2可能看到z=3, x=0, y=0，然后判断失败，但实际上thread1已经执行完了，只是顺序乱了。

正确做法：用mutex或atomic

如果是简单的标志位，用atomic：

std::atomic<bool>ready(false);voidthread1(){// 准备数据data.x=1;data.y=2;data.z=3;ready.store(true,std::memory_order_release);// 保证前面的写操作都完成}voidthread2(){if(ready.load(std::memory_order_acquire)){// 保证能看到前面的写操作// 安全使用data}}

memory_order_release和memory_order_acquire配对使用，保证了内存序，thread2看到ready=true时，一定能看到thread1对data的所有修改，这是因为release语义保证了之前的所有写操作都完成，acquire语义保证了之后的所有读操作都能看到，形成了一个同步点。

如果是复杂的数据结构，用mutex：

std::mutex mtx;SharedData data;voidthread1(){std::lock_guard<std::mutex>lock(mtx);data.x=1;data.y=2;data.z=3;}voidthread2(){std::lock_guard<std::mutex>lock(mtx);if(data.x==1&&data.y==2&&data.z==3){// 做点什么}}

mutex保证了互斥访问，同一时刻只有一个线程能访问data，不会出现中间状态，虽然性能比atomic稍差（因为涉及锁的获取释放开销，以及在高竞争场景下可能的内核态切换和上下文切换），但对于复杂数据结构来说，这是最简单、最可靠的方案。

错误3：以为volatile能防止指令重排

很多人以为volatile能防止指令重排序。这是对volatile最大的误解。

看这个经典的双重检查锁定（Double-Checked Locking）：

volatileSingleton*instance=nullptr;Singleton*getInstance(){if(instance==nullptr){// 第一次检查lock();if(instance==nullptr){// 第二次检查instance=newSingleton();// 问题在这里}unlock();}returninstance;}

这段代码看起来很聪明，用volatile保证instance的可见性，用双重检查减少锁的开销，但它是错的。

问题出在new Singleton()，这个操作实际上是三步：分配内存、在内存上构造Singleton对象、把内存地址赋值给instance，而编译器和CPU可能会重排成：分配内存、把内存地址赋值给instance（此时对象还没构造完）、在内存上构造Singleton对象，如果线程A执行到第2步，instance已经不是nullptr了，但对象还没构造完，这时线程B进来，第一次检查发现instance不是nullptr，直接返回了一个未构造完的对象，程序崩溃。

volatile不能防止这种重排。它只保证对volatile变量的访问不会被优化掉，但不保证访问的顺序。

正确做法：用atomic + memory_order

std::atomic<Singleton*>instance(nullptr);Singleton*getInstance(){Singleton*tmp=instance.load(std::memory_order_acquire);if(tmp==nullptr){lock();tmp=instance.load(std::memory_order_acquire);if(tmp==nullptr){tmp=newSingleton();instance.store(tmp,std::memory_order_release);}unlock();}returntmp;}

memory_order_release保证了new Singleton()的所有操作（分配内存、构造对象）都完成后，才把地址写入instance，memory_order_acquire保证了读取instance时，能看到对象的完整状态，锁内的第二次检查也使用acquire，确保如果另一个线程已经创建了实例，当前线程能看到完全构造好的对象，这两个内存序配合使用，形成了一个完整的同步机制，彻底解决了双重检查锁定的问题。

或者更简单，用C++11的局部静态变量：

Singleton&getInstance(){staticSingleton instance;// C++11保证线程安全returninstance;}

C++11标准保证了局部静态变量的初始化是线程安全的。编译器会自动加锁，保证只初始化一次。

那volatile到底该怎么用？

说了这么多volatile不能做的事，那它到底能做什么？

volatile的设计初衷是处理"内存映射I/O"和"信号处理"。

场景1：硬件寄存器

volatileuint32_t*gpio_register=(uint32_t*)0x40020000;*gpio_register=0x01;// 写入硬件寄存器

硬件寄存器的值可能随时变化（比如GPIO输入），编译器不能假设它的值不变，volatile告诉编译器：每次都从这个地址读取，不要优化，因为硬件可能在任何时候修改这个值，编译器的优化假设（“这个变量我刚读过，值不会变”）在这里不成立。

场景2：信号处理函数

volatilesig_atomic_t flag=0;voidsignal_handler(intsig){flag=1;}intmain(){signal(SIGINT,signal_handler);while(flag==0){// 等待信号}}

信号处理函数可能在任何时候被调用，修改flag的值，volatile保证编译器不会把while (flag == 0)优化成死循环，因为编译器可能认为"flag在循环里没被修改，可以优化成if (flag == 0) { while(1); }“，但信号处理函数是异步的，编译器看不到这个修改，volatile就是告诉编译器"这个变量可能被外部修改，别优化”。

但注意：这两个场景都是单线程的。

在多线程中，volatile不够用。你需要atomic、mutex、或者其他同步原语。