深入理解Linux内存优化：如何使用屏障提升性能

在当今快节奏的数字时代，无论是运行大型数据库的服务器，还是流畅播放高清视频的多媒体设备，亦或是精准控制生产流程的工业控制系统，其背后的 Linux 系统都肩负着高效管理内存的重任。内存管理，作为 Linux 内核的核心职能之一，就如同精密仪器中的齿轮组，有条不紊地协调着数据的存储与读取，为上层应用的稳定运行筑牢根基。

然而，随着计算机硬件性能的突飞猛进，尤其是多核处理器的广泛普及，内存访问的复杂性也呈指数级增长。为了充分挖掘硬件潜力，提升系统整体性能，现代计算机往往采用乱序执行、缓存机制等优化手段。但这也带来了新的挑战：内存操作的顺序可能变得难以捉摸，数据一致性问题时有发生，进而影响到应用程序的正确性与稳定性。

在这一背景下，内存优化屏障应运而生，它宛如一把精准的 “秩序之锁”，巧妙地控制着内存操作的先后顺序，确保在复杂的硬件架构与优化策略下，数据依然能够按照开发者预期的方式流动。那么，内存优化屏障究竟是如何在 Linux 系统中发挥作用的？它又能为我们的应用性能带来怎样的提升？接下来，就让我们一同揭开 Linux 内存优化屏障的神秘面纱，探寻其中的奥秘 。

一、内存屏障简介

1.1内存屏障概述

在计算机系统中，为了提升性能，现代 CPU 和编译器常常会对指令进行重排序。指令重排序是指在不改变程序最终执行结果的前提下，调整指令的执行顺序，以充分利用 CPU 的资源，提高执行效率 。例如，当 CPU 执行一系列指令时，如果某些指令之间不存在数据依赖关系，CPU 可能会先执行后面的指令，再执行前面的指令。

在单线程环境下，指令重排序通常不会带来问题，因为程序的执行结果仍然符合预期。然而，在多线程环境中，指令重排序可能会导致意想不到的结果，因为不同线程之间的操作可能会相互干扰。比如，线程 A 和线程 B 同时访问共享内存，线程 A 对共享变量的修改可能不会立即被线程 B 看到，这就导致了数据可见性问题。

为了解决这些问题，内存优化屏障应运而生。内存优化屏障是一种特殊的指令或机制，它可以阻止 CPU 和编译器对特定指令进行重排序，从而保证内存操作的顺序性和可见性。通过使用内存优化屏障，程序员可以确保在多线程环境下，内存操作按照预期的顺序执行，避免数据竞争和其他并发问题。

1.2为什么会出现内存屏障？

由于现在计算机存在多级缓存且多核场景，为了保证读取到的数据一致性以及并行运行时所计算出来的结果一致，在硬件层面实现一些指令，从而来保证指定执行的指令的先后顺序。比如上图：双核cpu，每个核心都拥有独立的一二级缓存，而缓存与缓存之间需要保证数据的一致性所以这里才需要加添屏障来确保数据的一致性。三级缓存为各CPU共享，最后都是主内存，所以这些存在交互的CPU都需要通过屏障手段来保证数据的唯一性。

内存屏障存在的意义就是为了解决程序在运行过程中出现的内存乱序访问问题，内存乱序访问行为出现的理由是为了提高程序运行时的性能，Memory Bariier能够让CPU或编译器在内存访问上有序。

在进一步剖析为什么会出现内存屏障之前，如果你对Cache原理还不了解，强烈建议先阅读一下这篇探秘CPU Cache：解锁计算机性能的幕后英雄，对Cache有了一定的了解之后，再阅读下面的内容。

(1)运行时内存乱序访问

运行时，CPU本身是会乱序执行指令的。早期的处理器为有序处理器（in-order processors）,总是按开发者编写的顺序执行指令， 如果指令的输入操作对象（input operands）不可用（通常由于需要从内存中获取）， 那么处理器不会转而执行那些输入操作对象可用的指令，而是等待当前输入操作对象可用。

相比之下，乱序处理器（out-of-order processors）会先处理那些有可用输入操作对象的指令（而非顺序执行） 从而避免了等待，提高了效率。现代计算机上，处理器运行的速度比内存快很多， 有序处理器花在等待可用数据的时间里已可处理大量指令了。即便现代处理器会乱序执行， 但在单个CPU上，指令能通过指令队列顺序获取并执行，结果利用队列顺序返回寄存器堆（详情可参考http:// http://en.wikipedia.org/wiki/Out-of-order_execution），这使得程序执行时所有的内存访问操作看起来像是按程序代码编写的顺序执行的， 因此内存屏障是没有必要使用的（前提是不考虑编译器优化的情况下）。

(2)SMP架构需要内存屏障的进一步解释：

从体系结构上来看，首先在SMP架构下，每个CPU与内存之间，都配有自己的高速缓存（Cache），以减少访问内存时的冲突采用高速缓存的写操作有两种模式：

(1). 穿透(Write through)模式，每次写时，都直接将数据写回内存中，效率相对较低；
(2). 回写(Write back)模式，写的时候先写回告诉缓存，然后由高速缓存的硬件再周转复用缓冲线(Cache Line)时自动将数据写回内存，
     或者由软件主动地“冲刷”有关的缓冲线(Cache Line)。

出于性能的考虑，系统往往采用的是模式2来完成数据写入；正是由于存在高速缓存这一层，正是由于采用了Write back模式的数据写入，才导致在SMP架构下，对高速缓存的运用可能改变对内存操作的顺序。

已上面的一个简短代码为例：

// thread 0 -- 在CPU0上运行
x = 42;
ok = 1;
 
// thread 1 – 在CPU1上运行
while(!ok);
print(x);

这里CPU1执行时， x一定是打印出42吗？让我们来看看以下图为例的说明：

假设，正好CPU0的高速缓存中有x，此时CPU0仅仅是将x=42写入到了高速缓存中，另外一个ok也在高速缓存中，但由于周转复用高速缓冲线（Cache Line）而导致将ok=1刷会到了内存中，此时CPU1首先执行对ok内存的读取操作，他读到了ok为1的结果，进而跳出循环，读取x的内容，而此时，由于实际写入的x(42)还只在CPU0的高速缓存中，导致CPU1读到的数据为x(17)。

程序中编排好的内存访问顺序（指令序：program ordering）是先写入x，再写入y。而实际上出现在该CPU外部，即系统总线上的次序（处理器序：processor ordering），却是先写入y，再写入x(这个例子中x还未写入)。

在SMP架构中，每个CPU都只知道自己何时会改变内存的内容，但是都不知道别的CPU会在什么时候改变内存的内容，也不知道自己本地的高速缓存中的内容是否与内存中的内容不一致。

反过来，每个CPU都可能因为改变了内存内容，而使得其他CPU的高速缓存变的不一致了。在SMP架构下，由于高速缓存的存在而导致的内存访问次序（读或写都有可能书序被改变）的改变很有可能影响到CPU间的同步与互斥。

因此需要有一种手段，使得在某些操作之前，把这种“欠下”的内存操作（本例中的x=42的内存写入）全都最终地、物理地完成，就好像把欠下的债都结清，然后再开始新的（通常是比较重要的）活动一样。这种手段就是内存屏障，其本质原理就是对系统总线加锁。

回过头来，我们再来看看为什么非SMP架构（UP架构）下，运行时内存乱序访问不存在。

在单处理器架构下，各个进程在宏观上是并行的，但是在微观上却是串行的，因为在同一时间点上，只有一个进程真正在运行（系统中只有一个处理器）。

在这种情况下，我们再来看看上面提到的例子：

线程0和线程1的指令都将在CPU0上按照指令序执行。thread0通过CPU0完成x=42的高速缓存写入后，再将ok=1写入内存，此后串行的将thread0换出，thread1换入，及时此时x=42并未写入内存，但由于thread1的执行仍然是在CPU0上执行，他仍然访问的是CPU0的高速缓存，因此，及时x=42还未写回到内存中，thread1势必还是先从高速缓存中读到x=42，再从内存中读到ok=1。

综上所述，在单CPU上，多线程执行不存在运行时内存乱序访问，我们从内核源码也可得到类似结论（代码不完全摘录）

#define barrier() __asm__ __volatile__("": : :"memory") 
#define mb() alternative("lock; addl $0,0(%%esp)", "mfence", X86_FEATURE_XMM2) 
#define rmb() alternative("lock; addl $0,0(%%esp)", "lfence", X86_FEATURE_XMM2)

#ifdef CONFIG_SMP 
#define smp_mb() mb() 
#define smp_rmb() rmb() 
#define smp_wmb() wmb() 
#define smp_read_barrier_depends() read_barrier_depends() 
#define set_mb(var, value) do { (void) xchg(&var, value); } while (0) 
#else 
#define smp_mb() barrier() 
#define smp_rmb() barrier() 
#define smp_wmb() barrier() 
#define smp_read_barrier_depends() do { } while(0) 
#define set_mb(var, value) do { var = value; barrier(); } while (0) 
#endif

这里可看到对内存屏障的定义，如果是SMP架构，smp_mb定义为mb()，mb()为CPU内存屏障（接下来要谈的），而非SMP架构时（也就是UP架构），直接使用编译器屏障，运行时内存乱序访问并不存在。

(3)为什么多CPU情况下会存在内存乱序访问？

我们知道每个CPU都存在Cache，当一个特定数据第一次被其他CPU获取时，此数据显然不在对应CPU的Cache中（这就是Cache Miss）。

这意味着CPU要从内存中获取数据（这个过程需要CPU等待数百个周期），此数据将被加载到CPU的Cache中，这样后续就能直接从Cache上快速访问。

当某个CPU进行写操作时，他必须确保其他CPU已将此数据从他们的Cache中移除（以便保证一致性），只有在移除操作完成后，此CPU才能安全地修改数据。

显然，存在多个Cache时，必须通过一个Cache一致性协议来避免数据不一致的问题，而这个通信的过程就可能导致乱序访问的出现，也就是运行时内存乱序访问。

受篇幅所限，这里不再深入讨论整个细节，有兴趣的读者可以研究《Memory Barriers: a Hardware View for Software Hackers》这篇文章，它详细地分析了整个过程。

现在通过一个例子来直观地说明多CPU下内存乱序访问的问题：

volatile int x, y, r1, r2;
//thread 1
void run1()
{
    x = 1;
    r1 = y;
}
 
//thread 2
void run2
{
    y = 1;
    r2 = x;
}

变量x、y、r1、r2均被初始化为0，run1和run2运行在不同的线程中。

如果run1和run2在同一个cpu下执行完成，那么就如我们所料，r1和r2的值不会同时为0，而假如run1和run2在不同的CPU下执行完成后，由于存在内存乱序访问的可能，这时r1和r2可能同时为0。我们可以使用CPU内存屏障来避免运行时内存乱序访问(x86_64)：

void run1()
{
    x = 1;
    //CPU内存屏障，保证x=1在r1=y之前执行
    __asm__ __volatile__("mfence":::"memory");
    r1 = y;
}

//thread 2
void run2
{
    y = 1;
    //CPU内存屏障，保证y = 1在r2 = x之前执行
    __asm__ __volatile__("mfence":::"memory");
    r2 = x;
}

二、内存屏障核心原理

2.1编译器优化与优化屏障

在程序编译阶段，编译器为了提高代码的执行效率，会对代码进行优化，其中指令重排是一种常见的优化手段。例如，对于下面的 C 代码：

int a = 1;
int b = 2;

在没有数据依赖的情况下，编译器可能会将其编译成汇编代码时，交换这两条指令的顺序，先执行b = 2，再执行a = 1。在单线程环境下，这种重排通常不会影响程序的最终结果。但在多线程环境中，当多个线程共享数据时，这种重排可能会导致数据一致性问题 。

为了禁止编译器对特定指令进行重排，Linux 内核提供了优化屏障机制。在 Linux 内核中，通过barrier()宏来实现优化屏障 。barrier()宏的定义如下：

#define barrier() __asm__ __volatile__("" ::: "memory")

__asm__表示这是一段汇编代码，__volatile__告诉编译器不要对这段代码进行优化，即不要改变其前后代码块的顺序 。"memory"表示内存中的变量值可能会发生变化，编译器不能使用寄存器中的值来优化，而应该重新从内存中加载变量的值。这样，在barrier()宏之前的指令不会被移动到barrier()宏之后，之后的指令也不会被移动到之前，从而保证了编译器层面的指令顺序。

2.2CPU 执行优化与内存屏障

现代 CPU 为了提高执行效率，采用了超标量体系结构和乱序执行技术。CPU 在执行指令时，会按照程序顺序取出一批指令，分析找出没有依赖关系的指令，发给多个独立的执行单元并行执行，最后按照程序顺序提交执行结果，即 “顺序取指令，乱序执行，顺序提交执行结果” 。

例如，当 CPU 执行指令A需要从内存中读取数据，而这个读取操作需要花费较长时间时，CPU 不会等待指令A完成，而是会继续执行后续没有数据依赖的指令B、C等，直到指令A的数据读取完成，再继续执行指令A的后续操作 。

虽然 CPU 的乱序执行可以提高执行效率，但在某些情况下，这种乱序执行可能会导致问题。比如，在多处理器系统中，一个处理器修改数据后，可能不会把数据立即同步到自己的缓存或者其他处理器的缓存，导致其他处理器不能立即看到最新的数据。为了解决这个问题，需要使用内存屏障来保证 CPU 执行指令的顺序 。

内存屏障确保在屏障原语前的指令完成后，才会启动原语之后的指令操作。在不同的 CPU 架构中，有不同的指令来实现内存屏障的功能。例如，在 X86 系统中，以下这些汇编指令可以充当内存屏障：

• 所有操作 I/O 端口的指令；

• 前缀lock的指令，如lock;addl $0,0(%esp)，虽然这条指令本身没有实际意义（对栈顶保存的内存地址内的内容加上 0），但lock前缀对数据总线加锁，从而使该条指令成为内存屏障；

• 所有写控制寄存器、系统寄存器或 debug 寄存器的指令（比如，cli和sti指令，可以改变eflags寄存器的IF标志）；

• lfence、sfence和mfence汇编指令，分别用来实现读内存屏障、写内存屏障和读 / 写内存屏障；

• 特殊的汇编指令，比如iret指令，可以终止中断或异常处理程序。

在 ARM 系统中，则使用ldrex和strex汇编指令实现内存屏障。这些内存屏障指令能够阻止 CPU 对指令的乱序执行，确保内存操作的顺序性和可见性，从而保证多线程环境下程序的正确执行。

三、内存屏障的多元类型与功能详解

在 Linux 系统中，内存屏障主要包括通用内存屏障、读内存屏障、写内存屏障和读写内存屏障，它们各自在保证内存操作的顺序性和可见性方面发挥着关键作用 。

3.1通用内存屏障

通用内存屏障（mb）确保在其之前的所有内存读写操作都在其之后的内存读写操作之前完成 。它保证了其前后的读写指令顺序，防止编译器和 CPU 对这些指令进行重排序。在 Linux 内核中，mb()函数被定义用来实现通用内存屏障，其定义如下：

#ifdef CONFIG_SMP
    #define mb() asm volatile("mfence" ::: "memory")
#else
    #define mb() barrier()
#endif

在 SMP（对称多处理）系统中，如果是 64 位 CPU 或支持mfence指令的 32 位 CPU，mb()宏被定义为asm volatile("mfence" ::: "memory") 。mfence指令是 x86 架构下的一条汇编指令，它会使 CPU 等待，直到之前所有的内存读写操作都完成，才会执行之后的内存操作，从而保证了内存操作的顺序性。

asm volatile表示这是一段汇编代码，并且禁止编译器对其进行优化，::: "memory"告诉编译器内存中的数据可能会被修改，不能依赖寄存器中的旧值 。在单处理器（UP）系统中，mb()被定义为barrier()，barrier()宏通过asm volatile("":::"memory")` 来实现，同样是为了防止编译器对内存操作进行重排序 。

3.2读内存屏障

读内存屏障（rmb）保证在其之前的所有读操作都在其之后的读操作之前完成 。它确保了读指令的顺序，防止读操作被重排序。在多线程环境中，当多个线程同时读取共享数据时，读内存屏障可以保证每个线程读取到的数据是按照预期的顺序更新的 。

例如，在一个多线程程序中，线程 A 和线程 B 都需要读取共享变量x和y的值，并且要求先读取x，再读取y。如果没有使用读内存屏障，由于指令重排序，线程 B 可能会先读取y，再读取x，导致读取到的数据不符合预期 。通过在读取x和y之间插入读内存屏障，就可以保证线程 B 先读取x，再读取y，从而保证了数据的一致性 。

在 Linux 内核中，rmb()函数的定义如下：

#ifdef CONFIG_SMP
    #define rmb() asm volatile("lfence" ::: "memory")
#else
    #define rmb() barrier()
#endif

在 SMP 系统中，如果是 64 位 CPU 或支持lfence指令的 32 位 CPU，rmb()宏被定义为asm volatile("lfence" ::: "memory") 。lfence指令是 x86 架构下的读内存屏障指令，它保证了在其之前的读操作都完成后，才会执行之后的读操作 。在 UP 系统中，rmb()同样被定义为barrier() 。

3.3写内存屏障

写内存屏障（wmb）保证在其之前的所有写操作都在其之后的写操作之前完成 。它确保了写指令的顺序，防止写操作被重排序。在数据更新场景中，写内存屏障尤为重要。例如，在一个多线程程序中，线程 A 需要先更新共享变量x，再更新共享变量y，并且要求其他线程能够按照这个顺序看到更新后的值 。

如果没有使用写内存屏障，由于指令重排序，其他线程可能会先看到y的更新，再看到x的更新，导致数据不一致 。通过在更新x和y之间插入写内存屏障，就可以保证其他线程先看到x的更新，再看到y的更新，从而保证了数据的一致性 。

在 Linux 内核中，wmb()函数的定义如下：

#ifdef CONFIG_SMP
    #define wmb() asm volatile("sfence" ::: "memory")
#else
    #define wmb() barrier()
#endif

在 SMP 系统中，如果是 64 位 CPU 或支持sfence指令的 32 位 CPU，wmb()宏被定义为asm volatile("sfence" ::: "memory") 。sfence指令是 x86 架构下的写内存屏障指令，它保证了在其之前的写操作都完成后，才会执行之后的写操作 。在 UP 系统中，wmb()也被定义为barrier() 。

3.4读写内存屏障

读写内存屏障既保证了读操作的顺序，也保证了写操作的顺序 。它确保了在其之前的所有读写操作都在其之后的读写操作之前完成 。在一些复杂的数据结构读写场景中，读写内存屏障非常有用。例如，在一个多线程程序中，线程 A 需要先写入数据到共享数据结构，然后读取该数据结构中的其他部分；线程 B 则需要先读取线程 A 写入的数据，然后再写入新的数据 。通过在这些读写操作之间插入读写内存屏障，可以保证线程 A 和线程 B 的读写操作按照预期的顺序进行，避免数据竞争和不一致的问题 。

在 Linux 内核中，并没有专门定义一个独立的读写内存屏障函数，通常可以使用通用内存屏障mb()来实现读写内存屏障的功能，因为mb()同时保证了读写操作的顺序 。

四、应用案例深度解析

4.1多核处理器环境下的同步

在多核处理器环境中，每个核心都有自己的高速缓存，当多个核心同时访问共享内存时，就可能出现缓存一致性问题 。例如，核心 A 修改了共享内存中的数据，并将其写入自己的缓存，但此时核心 B 的缓存中仍然是旧数据。如果核心 B 继续从自己的缓存中读取数据，就会读到不一致的数据 。

为了解决这个问题，内存屏障被广泛应用。内存屏障可以确保在屏障之前的内存操作都完成后，才会执行屏障之后的内存操作，从而保证了缓存一致性 。例如，在 X86 架构中，mfence指令可以作为内存屏障，它会使 CPU 等待，直到之前所有的内存读写操作都完成，才会执行之后的内存操作 。

在多线程编程中，当一个线程修改了共享数据后，通过插入内存屏障，可以确保其他线程能够立即看到这个修改 。假设线程 A 和线程 B 共享一个变量x，线程 A 修改了x的值后，插入一个内存屏障，然后线程 B 读取x的值，由于内存屏障的作用，线程 B 读取到的一定是线程 A 修改后的最新值 。

4.2设备驱动开发中的应用

在设备驱动开发中，内存屏障也起着关键作用。设备驱动程序需要与硬件设备进行交互，而硬件设备的操作通常需要按照特定的顺序进行 。例如，在对硬件寄存器进行操作时，必须确保先写入配置信息，再启动设备 。如果没有内存屏障，编译器和 CPU 可能会对这些操作进行重排序，导致设备无法正常工作 。

以串口驱动为例，在向串口发送数据时，需要先检查串口发送缓冲区是否为空，然后再将数据写入缓冲区 。如果这两个操作被重排序，就可能导致数据丢失 。通过在这两个操作之间插入内存屏障，可以确保先检查缓冲区，再写入数据，从而保证串口通信的正确性 。在 Linux 内核中，串口驱动代码可能会如下实现：

// 检查串口发送缓冲区是否为空
while (readl(serial_port + STATUS_REGISTER) & TX_FIFO_FULL);
// 插入写内存屏障
wmb();
// 将数据写入串口发送缓冲区
writel(data, serial_port + DATA_REGISTER);

在这个例子中，wmb()函数作为写内存屏障，确保了在写入数据之前，先完成对缓冲区状态的检查，从而保证了串口驱动的正常工作 。

4.3RCU 机制中的关键角色

RCU（Read - Copy - Update）机制是 Linux 内核中一种高效的同步机制，主要用于读多写少的场景 。在 RCU 机制中，内存屏障发挥着至关重要的作用 。

在 RCU 中，读操作不需要加锁，这大大提高了读操作的效率 。然而，为了保证数据的一致性，在写操作时需要采取一些特殊的措施 。当一个写者需要更新数据时，它首先会创建一个数据的副本，在副本上进行修改，然后将修改后的副本替换原来的数据 。在这个过程中，内存屏障用于确保读操作能够看到正确的数据 。

例如，在 Linux 内核的链表操作中，经常会使用 RCU 机制 。当一个线程要向链表中插入一个新节点时，它会先创建新节点，设置好节点的指针，然后使用rcu_assign_pointer函数来更新链表的指针 。rcu_assign_pointer函数内部会使用内存屏障，确保在新节点的指针设置完成后，其他线程才能看到这个新节点 。这样，在多线程环境下，读线程可以在不加锁的情况下安全地遍历链表，而写线程也可以在不影响读线程的情况下更新链表，从而提高了系统的并发性能 。

4.4内存一致性模型

内存一致性模型（Memory Consistency Model）是用来描述多线程对共享存储器的访问行为，在不同的内存一致性模型里，多线程对共享存储器的访问行为有非常大的差别。这些差别会严重影响程序的执行逻辑，甚至会造成软件逻辑问题。

不同的处理器架构，使用了不同的内存一致性模型，目前有多种内存一致性模型，从上到下模型的限制由强到弱：

• 顺序一致性（Sequential Consistency）模型

• 完全存储定序（Total Store Order）模型

• 部分存储定序（Part Store Order）模型

• 宽松存储（Relax Memory Order）模型

注意，这里说的内存模型是针对可以同时执行多线程的平台，如果只能同时执行一个线程，也就是系统中一共只有一个CPU核，那么它一定是满足顺序一致性模型的。

对于内存的访问，我们只关心两种类型的指令的顺序，一种是读取，一种是写入。对于读取和加载指令来说，它们两两一起，一共有四种组合：

• LoadLoad：前一条指令是读取，后一条指令也是读取。

• LoadStore：前一条指令是读取，后一条指令是写入。

• StoreLoad：前一条指令是写入，后一条指令是读取。

• StoreStore：前一条指令是写入，后一条指令也是写入。

①顺序一致性模型

顺序存储模型是最简单的存储模型，也称为强定序模型。CPU会按照代码来执行所有的读取与写入指令，即按照它们在程序中出现的次序来执行。同时，从主存储器和系统中其它CPU的角度来看，感知到数据变化的顺序也完全是按照指令执行的次序。也可以理解为，在程序看来，CPU不会对指令进行任何重排序的操作。在这种模型下执行的程序是完全不需要内存屏障的。但是，带来的问题就是性能会比较差，现在已经没有符合这种内存一致性模型的系统了。

为了提高系统的性能，不同架构都会或多或少的对这种强一致性模型进行了放松，允许对某些指令组合进行重排序。注意，这里处理器对读取或写入操作的放松，是以两个操作之间不存在数据依赖性为前提的，处理器不会对存在数据依赖性的两个内存操作做重排序。

②完全存储定序模型

这种内存一致性模型允许对StoreLoad指令组合进行重排序，如果第一条指令是写入，第二条指令是读取，那么有可能在程序看来，读取指令先于写入指令执行。但是，对于其它另外三种指令组合还是可以保证按照顺序执行。

这种模型就相当于前面提到的，在CPU和缓存中间加入了存储缓冲，而且这个缓冲还是一个满足先入先出（FIFO）的队列。先入先出队列就保证了对StoreStore这种指令组合也能保证按照顺序被感知。

我们非常熟悉的X86架构就是使用的这种内存一致性模型。

③部分存储定序模型

这种内存一致性模型除了允许对StoreLoad指令组合进行重排序外，还允许对StoreStore指令组合进行重排序。但是，对于其它另外两种指令组合还是可以保证按照顺序执行。

这种模型就相当于也在CPU和缓存中间加入了存储缓冲，但是这个缓冲不是先入先出的。

④宽松存储模型

这种内存一致性模型允许对上面说的四种指令组合都进行重排序。

这种模型就相当于前面说的，既有存储缓冲，又有无效队列的情况。

这种内存模型下其实还有一个细微的差别，就是所谓的数据依赖性的问题。例如下面的程序，假设变量A初始值是0：

CPU 0	CPU 1
A = 1;	Q = P;
<write barrier>	B = *Q;
P = &A;

五、使用注意事项与性能考量

5.1避免过度使用

虽然内存屏障是解决多线程环境下内存一致性问题的有力工具，但过度使用会对系统性能产生负面影响 。内存屏障会阻止 CPU 和编译器对指令进行重排序，这在一定程度上限制了它们的优化能力，从而增加了指令执行的时间 。在一些不必要的场景中使用内存屏障，会导致性能下降 。

例如，在单线程环境中，由于不存在多线程并发访问共享数据的问题，使用内存屏障是完全没有必要的，这只会浪费系统资源 。在多线程环境中，如果共享数据的访问没有数据竞争问题，也不应随意使用内存屏障 。比如，在一个多线程程序中，多个线程只是读取共享数据，而不进行写操作，此时使用内存屏障并不能带来任何好处，反而会降低性能 。因此，在使用内存屏障时，需要仔细分析代码的执行逻辑和数据访问模式，确保只在必要的地方使用内存屏障，以避免不必要的性能损失 。

5.2选择合适的屏障类型

不同类型的内存屏障在功能和适用场景上有所不同，因此根据具体的场景选择合适的内存屏障类型至关重要 。如果只需要保证读操作的顺序，那么使用读内存屏障（rmb）即可；如果只需要保证写操作的顺序，使用写内存屏障（wmb）就足够了 。在一些复杂的场景中，可能需要同时保证读写操作的顺序，这时就需要使用通用内存屏障（mb）或读写内存屏障 。

例如，在一个多线程程序中，线程 A 需要先读取共享变量x，再读取共享变量y，并且要求这两个读操作按照顺序进行，此时就可以在读取x和y之间插入读内存屏障 。如果线程 A 需要先写入共享变量x，再写入共享变量y，并且要求其他线程能够按照这个顺序看到更新后的值，那么就应该在写入x和y之间插入写内存屏障 。在一些涉及复杂数据结构读写的场景中，可能需要使用通用内存屏障来保证读写操作的顺序 。

比如，在一个多线程程序中，线程 A 需要先写入数据到共享链表，然后读取链表中的其他部分，线程 B 则需要先读取线程 A 写入的数据，然后再写入新的数据，这种情况下就可以使用通用内存屏障来确保线程 A 和线程 B 的读写操作按照预期的顺序进行 。因此，在使用内存屏障时，需要根据具体的场景和需求，选择合适的内存屏障类型，以充分发挥内存屏障的作用，同时避免不必要的性能开销 。

5.3性能监测与优化

为了确保内存屏障的使用不会对系统性能造成过大的影响，使用工具监测内存屏障对性能的影响，并根据监测结果进行优化是很有必要的 。在 Linux 系统中，可以使用 perf 工具来监测内存屏障对性能的影响 。perf 是一个性能分析工具，它可以收集系统的性能数据，包括CPU使用率、内存访问次数等 。通过使用perf 工具，可以了解内存屏障的使用对系统性能的影响，从而找到性能瓶颈，并进行优化 。

例如，可以使用 perf record 命令来收集性能数据，然后使用 perf report 命令来查看性能报告 。在性能报告中，可以看到各个函数的 CPU 使用率、内存访问次数等信息，从而找到内存屏障使用较多的函数，并分析其对性能的影响 。如果发现某个函数中内存屏障的使用导致了性能下降，可以尝试优化该函数的代码，减少内存屏障的使用，或者选择更合适的内存屏障类型 。

除了使用 perf 工具外，还可以通过代码优化、算法改进等方式来提高系统性能 。例如，可以减少不必要的内存访问，优化数据结构，提高代码的并行性等 。通过综合使用这些方法，可以有效地提高系统性能，确保内存屏障的使用不会对系统性能造成过大的影响 。