17、内存屏障：编译器屏障与CPU屏障、volatile关键字
内存屏障这个话题，说实话有点绕。我第一次接触它的时候，也花了好几天才理清楚。你想想看，我们写代码时明明是按顺序写的，可到了实际执行时，顺序却可能被打乱——这就是乱序执行。为什么会这样？因为编译器和CPU都在偷偷优化你的代码。
我当年在一个嵌入式项目中就吃过这个亏。一个多线程的共享标志位，我明明在主线程里先写数据、后置标志，结果另一个线程看到标志位变了，去读数据时却读到旧值。排查了整整两天，最后发现是编译器把赋值顺序给重排了。嗯，从那以后，我对内存屏障就格外上心。
什么是内存屏障
内存屏障，说白了就是一道「墙」。它告诉编译器和CPU：墙前面的操作必须完成，墙后面的操作才能开始。不能跨墙乱跑。
它解决的核心问题有两个：
- 编译器乱序——编译器为了优化，会重新排列你的代码顺序
- CPU乱序——CPU为了提升流水线效率，也会打乱指令执行顺序
这两种乱序，都会导致多线程环境下出现诡异的问题。你明明按顺序写的代码，结果跑起来就不是那么回事了。
编译器屏障
编译器屏障，也叫优化屏障。它只影响编译器，不影响CPU。在GCC中，最常用的编译器屏障是：
asm volatile("" ::: "memory");这行代码告诉编译器：这里有个内存屏障，你优化的时候别越过这条线。具体来说：
asm——内联汇编volatile——告诉编译器不要优化掉这个汇编语句::: "memory"——告诉编译器内存可能被修改了，所有缓存的值都要重新读取
我个人的习惯是，在驱动代码中频繁使用这个屏障。比如操作硬件寄存器时，编译器经常自作主张把两次连续的写操作合并成一次，这就会出大问题。
关键点：编译器屏障只阻止编译器乱序，不阻止CPU乱序。如果你的代码跑在多核CPU上，光靠编译器屏障是不够的。
CPU屏障
CPU屏障才是真正意义上的硬件级屏障。它会给CPU发一条指令，告诉它：前面的内存操作必须完成，后面的才能开始。
不同的CPU架构，屏障指令也不一样：
| 架构 | 屏障指令 | 说明 |
|---|---|---|
| x86 | mfence / lfence / sfence | mfence是全屏障，lfence是读屏障，sfence是写屏障 |
| ARM | dmb / dsb / isb | dmb是数据内存屏障，dsb是数据同步屏障 |
| RISC-V | fence | fence指令，可以指定前后操作类型 |
在Linux内核中，封装了通用的屏障宏：
#define mb() asm volatile("mfence" ::: "memory")
#define rmb() asm volatile("lfence" ::: "memory")
#define wmb() asm volatile("sfence" ::: "memory")你看，这里既包含了CPU屏障指令，又包含了编译器屏障的"memory"约束。双重保险。
小技巧：在x86架构下，带lock前缀的指令（如lock xchg）本身就带有全屏障的效果。所以很多原子操作不需要额外加屏障。
volatile关键字
volatile这个关键字，很多人理解错了。它告诉编译器：这个变量可能会被意想不到地改变，每次使用都必须从内存重新读取，不能优化到寄存器里。
volatile能解决什么问题？
- 读取硬件寄存器时，防止编译器缓存值
- 在信号处理函数中访问全局变量
- 在setjmp/longjmp中访问自动变量
但它不能解决什么问题？
- 不能保证原子性——volatile变量的读写仍然可能被中断打断
- 不能保证内存顺序——volatile不提供任何内存屏障语义
- 不能替代锁——多线程共享变量，光靠volatile是不够的
我曾经见过一个同事，用volatile修饰了一个共享标志位，以为这样就线程安全了。结果线上还是出了bug。为什么？因为volatile只保证每次从内存读，但不保证读和写之间的顺序。两个线程同时写这个标志位，照样会出问题。
注意：volatile不是原子操作。在多线程环境下，请使用C11的_Atomic类型或锁机制。volatile只适合单线程中的特殊场景，比如信号处理函数。
三种机制的关系
我把这三者的关系画了一张图，方便你理解：
从这张图可以看出，volatile和编译器屏障都只作用于编译器层面，而CPU屏障作用于硬件层面。在实际开发中，这三者经常配合使用。
实际应用场景
我举几个我在项目中遇到的真实场景：
- 设备驱动中的寄存器操作：硬件寄存器的读写顺序至关重要。比如先写控制寄存器，再读状态寄存器。编译器可能把读操作提前，导致读到错误的状态。这时候就需要加屏障。
- 多核共享数据：一个核写数据，另一个核读数据。如果没有屏障，读核可能看到的是部分写入的中间状态。这种情况需要CPU屏障。
- 中断处理函数：中断里修改了一个全局标志，主循环里检查这个标志。用volatile告诉编译器每次都要从内存读，但不需要CPU屏障（因为中断和主循环在同一个核上）。
总结一下：
- 单线程 + 中断：用volatile就够了
- 单线程 + 编译器优化过度：用编译器屏障
- 多核共享数据：必须用CPU屏障
- 多核 + 复杂场景：考虑用原子操作或锁，它们内部已经包含了屏障
最后说一句，内存屏障是个底层的东西。如果你在写应用层代码，尽量用锁、信号量、原子操作这些高级抽象。它们内部已经帮你处理好了屏障问题。只有写底层驱动、操作系统内核或者高性能并发库时，才需要直接跟内存屏障打交道。
嗯，这一章就到这里。记住一句话：乱序是常态，屏障是手段，正确才是目的。