想象你经营着一家繁忙的餐厅，几位大厨（CPU 核心）各占一个备料台（缓存），共同使用一个大冷藏库（主内存）。菜单就是你的程序，每道菜就是一条指令。麻烦在于：一位大厨把新熬的酱料放在了自己的备料台上，另一位大厨却全然不知，还用旧配料下锅；两位大厨同时向冷藏库取货，取到的食材却可能不是对方放进去的那一份。为了不让厨房乱套，餐厅需要一套“取放规则”——这就是硬件内存模型。有的厨房规矩严格（TSO），几乎所有操作都得按顺序来；有的厨房自由奔放（Relaxed），效率更高，但容易出错，必须靠“口令”在关键时刻喊停——这就是内存屏障（mfence/lfence/sfence）。理解这套规则，你才能驾驭多线程代码，写出既快又稳的程序。

岗位关联

对AI从业者来说，模型训练、推理服务、数据管道处处都是并发，搞懂内存模型能帮你定位“偶发崩溃”的隐藏 bug，写出高吞吐、无竞争的生产级代码。

目录
  1. 可视化演示
  2. 内存模型认知：后厨的规则手册
  3. TSO强顺序：严格按章办事
  4. Relaxed弱序：自由的代价
  5. 内存屏障：后厨的三种口令
  6. 缓存一致性：共享货架的学问
  7. 同步原语：门锁与钥匙
  8. 工程优化：从菜谱到实战
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

通过TSO重排序、内存屏障指令和内存序对比三个模式，展示x86/ARM处理器中内存操作顺序与屏障控制的完整机制。

本节配有交互动效（进入视口后自动加载，约 3KB）。

TSO Store-Load重排序 CPU0执行Store→Load时，Store先进入Store Buffer，Load可提前执行 导致Store-Load重排序，其他CPU可能观察到旧值 TSO: Store ↛ Load （允许重排） Store Buffer是TSO性能优化的关键，但也引入可见性问题

内存模型认知：后厨的规则手册

餐厅后厨一开始没有规则，大家各用各的备料台，结果一天晚上厨房混乱不堪：有人用了没腌的肉，有人把热菜放进了冷冻库。于是主厨制定了一本《后厨取放手册》，规定什么时候能看到别人的操作、操作必须按什么顺序发生。这本手册就是硬件内存模型。

在计算机世界里，内存模型是 CPU 与软件之间的一份“契约”。它回答两个核心问题：一个线程写入的值，在什么条件下能被另一个线程读取到？多个处理器的读写操作，被其他处理器观察到的顺序是什么？如果离开这份契约，多线程程序就等同于在黑暗的厨房里瞎忙。

内存模型中最基础的概念是“先发生”（happens-before）。当操作 A 先发生于操作 B 时，A 的结果对 B 是可见的。这里的“先发生”包含程序顺序、锁的获取释放、线程创建/join 等边界。在没有先发生关系的两个操作之间，CPU 和编译器都可以自由重排，这也是乱序 bug 的根源。

规则手册一页纸写满了“必须先发生才能被看到”，有了手册，大厨们才知道自己的辛苦不会白费。内存模型就是这样的手册，让线程之间的协作有据可依。

A hb B⇒visible(A,B)A \text{ hb } B \Rightarrow \text{visible}(A, B)
通俗说明：如果 A 在“先发生”关系上排在 B 前面，那么 A 写入的值一定能被 B 看到。
  1. 符号 A 和 B两个内存操作，例如 A 是某个变量的赋值，B 是另一个线程里读取该变量。
    A,BA, B
  2. hb 关系$\text{hb}$ 表示“先发生”（happens-before），即 A 在程序逻辑上先于 B。
    A hb BA \text{ hb } B
  3. 蕴含箭头$\Rightarrow$ 读作“那么”，表示如果左边条件满足，右边一定成立。
    X⇒YX \Rightarrow Y
  4. 可见性结论$\text{visible}(A, B)$ 表示 A 写入的值对 B 可见，B 能读到 A 的最新结果。
    visible(A,B)\text{visible}(A, B)

TSO强顺序：严格按章办事

TSO 就像一家规矩严格的餐厅，主厨要求所有大厨必须按“登记簿”顺序把菜放进冷藏库。即使你动作快，也必须排队登记，谁也不能插队。这套制度保证了写操作的全局顺序与程序顺序一致。

x86 处理器采用的总存储顺序（Total Store Order）是典型的强内存模型。它在每个 CPU 核心内部维护一个 FIFO（先进先出）的写缓冲（store buffer）。当一条 store 指令执行时，数据先写入写缓冲，再按顺序提交到缓存/内存。因为写缓冲是 FIFO，所以 store 指令之间的顺序不会被重排。

但 TSO 并不保证完全顺序一致。由于读操作可以从写缓冲旁路读取，或直接从内存读取，因此后发的 load 可能越过先前的 store 先执行，这就是 store-load 重排。经典的并发实验里，两个线程分别执行“写 x=1; 读 y”和“写 y=1; 读 x”，最终可能都读到 0，正是这个原因。

虽然登记簿顺序不能乱，但大厨们不必等酱料放进冰箱才切菜，可以先切着菜等酱料——只要登记顺序不乱，味道就差不了太多。TSO 的“强”就在于此：写操作的次序被牢牢锁住。

∀ i<j: Si→mSj\forall\, i < j:\ S_i \to_m S_j
通俗说明：对于任意两个 store 操作，只要程序顺序里第 i 个在前、第 j 个在后，那么在全局内存顺序里 i 也一定在前。
  1. 全称量词$\forall$ 表示“对于所有”，说明规则适用于一切符合条件的 store 对。
    ∀\forall
  2. 下标条件$i < j$ 表示在程序顺序中，第 i 个 store 先于第 j 个 store。
    i<ji < j
  3. store 操作$S_i$ 和 $S_j$ 是第 i 个和第 j 个 store（写内存）指令。
    Si, SjS_i,\ S_j
  4. 内存顺序$\to_m$ 表示“在全局内存顺序中先于”，因此 store 的全局顺序与程序顺序一致。
    Si→mSjS_i \to_m S_j

Relaxed弱序：自由的代价

另一家餐厅使用“自由厨房”模式，每位大厨按自己的节奏取放，效率高，但时常出现“我明明放了盐，另一位却说没看到”的情况。这种模式让厨房产出更高，却需要厨师们额外默契。

ARM、PowerPC 等架构采用宽松（Relaxed）内存模型，处理器和编译器可以对读/写指令进行更多重排。这是为了减少等待、提升流水线利用率。在宽松模型下，除了依赖关系（后一条操作依赖前一条的返回值）之外，一般内存操作之间不存在默认顺序保证。

这意味着什么？一个线程对变量 x 的写，另一个线程可能延迟很久才看到；甚至两个线程看到的 x/y 更新顺序可能相反。要想恢复顺序，程序员必须显式加入内存屏障，或使用带内存顺序语义的原子操作。换句话说，宽松模型把“对齐”的责任交给了程序员。

自由厨房里，想保证别人看到你的“加盐”动作，就得靠大声喊——这就是内存屏障。宽松模型给了性能自由度，也把秩序的责任交给了开发者。

∃ i<j: Oi̸→mOj\exists\, i < j:\ O_i \not\to_m O_j
通俗说明：存在某两个操作，即使程序顺序里 i 在前，全局内存顺序里 i 却不一定在前。
  1. 存在量词$\exists$ 表示“至少存在一个”，说明宽松模型下确实允许反例。
    ∃\exists
  2. 程序顺序$i < j$ 表示第 i 个操作先于第 j 个操作出现在指令流中。
    i<ji < j
  3. 任意操作$O_i, O_j$ 可以是 load，也可以是 store。
    Oi, OjO_i,\ O_j
  4. 否定顺序$\not\to_m$ 表示不保证在内存顺序中保持程序顺序，即可能被重排。
    Oi̸→mOjO_i \not\to_m O_j

内存屏障：后厨的三种口令

自由厨房里，主厨发明了三种口令：sfence 是“清货口令”，把所有做好的菜送进冷藏库并确认；lfence 是“取货口令”，确认所有要用的食材都已经从冷藏库搬到备料台；mfence 是“全清口令”，两者都做，完成一次彻底盘点。这些口令就是内存屏障。

内存屏障是 CPU 提供的特殊指令，用于强制屏障前后的内存操作顺序。x86 中有三种主要屏障：sfence（存储屏障）、lfence（加载屏障）、mfence（全屏障）。sfence 保证它之前的全部 store 在它之后的 store 之前提交；lfence 保证之前的 load 全部完成；mfence 同时保证 load 和 store 都已完成，形成一道完整的内存墙。

在编程中，屏障常被用作“围栏”，隔离重排。编译器不会把屏障两侧的某些操作互相移动，CPU 在遇到屏障时会冲刷流水线中的相关操作。这样，屏障前写得再乱，屏障后也能看到一致的结果。

口令一响，全厨房停下来对齐食材，虽然慢，但能保证菜式严格照谱。在宽松内存模型上编写多线程程序时，正确的屏障就是那条让全世界暂时安静下来的红线。

mfence: ∀ a∈P, b∈Q: a→mbmfence:\ \forall\, a \in P,\ b \in Q:\ a \to_m b
通俗说明：mfence 建立了一条分界线，分界线前的任何内存操作都先于分界线后的任何内存操作。
  1. P 和 Q 集合P 是屏障前的全部内存操作，Q 是屏障后的全部内存操作。
    P, QP,\ Q
  2. 全称量词$\forall$ 表示对 P 中的每一个 a 和 Q 中的每一个 b 都成立。
    ∀ a∈P, b∈Q\forall\, a \in P,\ b \in Q
  3. 顺序关系$a \to_m b$ 表示 a 在全局内存顺序上先于 b。
    a→mba \to_m b

缓存一致性：共享货架的学问

冷藏库里，几个大厨共享同一个货架，有人更新了食材，别人怎么知道？货架管理员会在各个备料台之间发广播，通知大家“某某食材已过期”。这个管理员就是缓存一致性协议。

现代 CPU 中，每个核心都有私有缓存，但它们必须保证对同一地址的读操作不会拿到陈旧数据。MESI 协议是最经典的缓存一致性协议，它用四个状态标记缓存行：Modified（修改）、Exclusive（独占）、Shared（共享）、Invalid（失效）。当一个核心写入某个缓存行时，其他核心中对应的缓存行会被标记为 Invalid，下次访问必须重新获取最新数据。

缓存一致性带来一个意外问题——伪共享（False Sharing）。多个线程访问的不同变量，如果恰好落在同一个缓存行，那么每次写其中一个变量都会导致对方缓存行失效，从而引发无谓的同步广播。这就像两位厨师分别改自己的调料瓶，却因为调料瓶放在同一个托盘上而频繁争抢托盘。

共享货架的管理让厨房井然有序，但也带来了“一个托盘连累两瓶调料”的烦恼。理解缓存行与伪共享，是写出可扩展多线程代码的第一步。

Tcontend≈Ncores×tinvalidateT_{contend} \approx N_{cores} \times t_{invalidate}
通俗说明：当发生伪共享时，每次写操作都要让其他核心的缓存行失效，总开销约等于核心数乘以单次失效广播的时间。
  1. 核心数$N_{cores}$ 是参与竞争的 CPU 核心数量。
    NcoresN_{cores}
  2. 单次失效广播$t_{invalidate}$ 是触发一次缓存一致性失效广播所需的平均时间。
    tinvalidatet_{invalidate}
  3. 乘积关系伪共享的竞争开销随核心数线性增长，这也是多核规模越大伪共享越严重的根源。
    Ncores×tinvalidateN_{cores} \times t_{invalidate}

同步原语：门锁与钥匙

冷藏库门口挂了一把锁，只有拿到钥匙的厨师才能进入取放食材，其他人必须等待。锁本身必须防抢——不能两个人同时把钥匙插进去。这把锁在计算机里就是同步原语。

锁、互斥量、条件变量等高级同步原语，底层依赖原子指令（如 CAS）和内存屏障。C++ 的 std::atomic 允许指定内存序：relaxed、acquire、release、seq_cst。其中 relaxed 只保证原子性，不保证顺序；acquire/release 用于配对实现“先发生”关系；seq_cst 提供全局一致顺序，但性能开销最大。

CAS（Compare And Swap）是实现无锁数据结构的基础。它比较目标变量与期望值，若相等则替换为新值并返回成功，否则不修改并返回失败。整个比较-交换过程由硬件保证原子，不会被其他核心打断。

锁就像厨房门锁，开门动作必须是原子的——不能两个人同时把钥匙插进去。任何高级同步，最终都落到 CAS 和屏障这样的小动作上。

CAS(p,old,new)={p←new, truep=oldfalseotherwiseCAS(p, old, new) = \begin{cases} p \leftarrow new,\ true & p = old\\ false & \text{otherwise} \end{cases}
通俗说明：CAS 只有两种情况：值等于旧值就更新并成功；否则放弃更新并报告失败。
  1. 参数 p内存地址，也就是要修改的变量。
    pp
  2. 成功分支当 p 当前值等于 old 时，把 p 更新为 new，并返回 true。
    p=old⇒p←new, truep = old \Rightarrow p \leftarrow new,\ true
  3. 失败分支否则不做任何修改，返回 false。
    otherwise⇒false\text{otherwise} \Rightarrow false

工程优化：从菜谱到实战

经验丰富的大厨知道哪类菜可以同时做，哪些菜必须严格同步；但高峰期也清楚，每个“口令”都会延误出菜速度。工程优化就是在正确性与性能之间找到平衡。

内存屏障和强内存序能恢复顺序，但代价是抑制 CPU 乱序执行，增加几十到几百周期的延迟。因此，能用 relaxed 就不必用 seq_cst；能减少屏障就减少屏障。编写多线程代码时，应优先使用语言提供的原子库，而不是手写内联汇编，以确保可移植性。

工程实践中，常犯的错误是把 volatile 当作线程安全标志。volatile 只告诉编译器不要优化对特定地址的访问，它既不能保证原子性，也不能阻止 CPU 重排。真正的共享状态应使用 std::atomic。排查并发 bug 时，可以使用 ThreadSanitizer 检测数据竞争，用性能分析工具观察缓存未命中与同步等待。

好的后厨会根据菜单和客流调整口令频率——该严格时严格，能并行时绝不排队。理解内存模型，就是学会在关键边界严格、在安全区域放手，从而写出既稳定又高效的系统。

Tstall≈β×NbarrierT_{stall} \approx \beta \times N_{barrier}
通俗说明：程序的总停顿时间大约等于每次屏障的平均开销乘以屏障数量，所以屏障不能乱加。
  1. β单次内存屏障带来的平均延迟，包含流水线冲刷与缓存同步开销。
    β\beta
  2. 屏障数量$N_{barrier}$ 是程序中屏障或同步点的总次数。
    NbarrierN_{barrier}
  3. 乘积$T_{stall}$ 表示同步引起的总停顿，暗示了屏障的成本随数量线性增长。
    β×Nbarrier\beta \times N_{barrier}

AI 应用场景

推理服务中的热更新与读可见性

阶段：推理服务并发调度

解决的问题：多线程读取共享模型参数时，可能读到旧的权重或半更新状态。传统做法用锁保护，但推理路径上锁竞争会显著抬高延迟。利用内存序的 release/acquire 语义，可以在不加锁的情况下安全发布新模型参数。

具体案例：某推理服务使用工作线程池处理请求，主线程在后台加载新权重，并通过 std::shared_ptr + std::atomic 以 release 顺序发布指针，消费者以 acquire 顺序加载指针。这样既保证新权重对所有线程可见，又避免了每次推理都加锁。

无锁日志队列的高性能采集

阶段：观测性数据采集

解决的问题：训练集群中日志多线程写入共享缓冲，若不加同步会出现记录丢失或乱序。使用无锁 MPSC 队列，入队用 memory_order_release，出队用 memory_order_acquire，可显著降低锁开销，保证日志顺序。

具体案例：在 PyTorch 分布式训练中，各 worker 的指标数据通过无锁队列汇入 collector，队列头部用 CAS 抢占槽位，写入完成后用 release 发布，collector 用 acquire 读取，日志吞吐提升约 3 倍。

参数服务器中的原子更新

阶段：参数同步

解决的问题：多个 worker 通过共享内存更新全局参数，需要处理缓存一致性和屏障成本，避免性能下降。

具体案例：参数服务器为每个模型参数维护一个原子计数器和版本号。worker 在本地聚合梯度后，以 relaxed 顺序递增版本号，再以 release 顺序发布参数更新；其他 worker 以 acquire 顺序读取。这样减少了锁等待，同时保证了参数更新的可见性边界。

Python 演示

python54 行
from itertools import permutations CPU0 = [('W', 'x'), ('R', 'y')]CPU1 = [('W', 'y'), ('R', 'x')] def permute(seq, model):    if model == 'SC':        return [seq]    if model == 'TSO':        variants = [seq]        # store-load 允许重排        if seq[0][0] == 'W' and seq[1][0] == 'R':            variants.append([seq[1], seq[0]])        return variants    if model == 'Relaxed':        return list(set(permutations(seq)))    return [] def interleave(a, b):    res = []    def rec(i, j, cur):        if i == len(a) and j == len(b):            res.append(cur)            return        if i < len(a):            rec(i + 1, j, cur + [a[i]])        if j < len(b):            rec(i, j + 1, cur + [b[j]])    rec(0, 0, [])    return res def execute(seq):    x = y = 0    r1 = r2 = None    for op, var in seq:        if op == 'W':            if var == 'x':                x = 1            else:                y = 1        else:            if var == 'y':                r1 = y            else:                r2 = x    return (r1, r2) for model in ['SC', 'TSO', 'Relaxed']:    results = set()    for p0 in permute(CPU0, model):        for p1 in permute(CPU1, model):            for seq in interleave(p0, p1):                results.add(execute(seq))    print(model, sorted(results))
目的：用一个小型模拟器展示不同硬件内存模型（SC/TSO/Relaxed）下，两个线程交错执行可能产生哪些不同的读取结果。
  1. CPU0 = [('W', 'x'), ('R', 'y')]CPU0 的指令序列：先写 x，再读 y。
  2. def permute(seq, model)根据内存模型生成该 CPU 允许的操作序列变体。
  3. if seq[0][0] == 'W' and seq[1][0] == 'R':在 TSO 下允许 store-load 重排，所以交换顺序生成新序列。
  4. return list(set(permutations(seq)))Relaxed 模型下所有操作排列都允许。
  5. rec(i + 1, j, cur + [a[i]])递归生成两个 CPU 指令序列的交错执行路径。
  6. print(model, sorted(results))输出每个内存模型下所有可能的结果组合，直观看到 Relaxed 比 SC/TSO 产生的可能性更多。

常见误区

误区很多初学者会写 `volatile bool running = true;`，以为另一个线程立刻就能看到修改，并且 volatile 能阻止重排。

正解volatile 只告诉编译器“不要优化掉对该地址的访问”，它既不保证原子性，也不提供任何内存顺序约束。CPU 依然可以乱序，缓存依然可能延迟同步。就像后厨贴张“请勿乱动”的纸条，并不能保证别人真的不动。线程间共享状态应使用 std::atomic 或锁。

为何常见：C 语言中 volatile 常用于硬件寄存器访问，给人“内存操作原样执行”的错觉，容易迁移到多线程编程。

误区既然屏障能修正乱序，那就处处加屏障，保证万无一失。

正解屏障会阻止 CPU 乱序执行与流水线优化，每次开销很大。在热点路径上滥用屏障，性能可能下降数倍。应该只在存在真实共享数据竞争且顺序关键的边界使用屏障。就像后厨每个动作后都喊一遍口令，会拖慢所有出菜。

为何常见：人们倾向于“多一道保险”，但忽略了屏障并非免费，而且很多场景下并不需要强顺序。

误区x86 是强内存模型，所以程序顺序就是执行顺序。

正解x86 的 TSO 保证了 store-store 顺序，但允许 store-load 重排，因为写缓冲让后续 load 可能先于之前的 store 完成。此外，编译器层次的指令重排依然存在。所以写出经典的并发实验，仍然可能得到两个读都为 0 的结果。

为何常见：强模型的“强”字容易让人误以为完全顺序一致，实际上 TSO 只是“部分强”。

误区只有一个核，共享内存不会被其他核抢占，所以不需要屏障。

正解单核 CPU 上仍然存在其他并发来源：设备 DMA、中断处理器、相同 CPU 上的信号处理器等。如果代码运行在操作系统内核或嵌入式系统，这些上下文可能异步访问同一内存区域。比如设备写 DMA 缓冲后，CPU 需要 dma_rmb() 确保读到完整数据。

为何常见：大多数教学都针对用户态多线程，默认多核场景，忽略了单核上的并发上下文切换。

误区把 x86 的屏障指令当成所有架构的通用指令，直接内联汇编到处用。

正解ARM、PowerPC 等架构有各自的屏障指令，如 ARM 的 dmb ish、dsb sy，语义与 x86 并不完全相同。写可移植代码时应使用语言层的原子库或内存序参数，避免直接依赖特定指令集。

为何常见：常见教材和文章多以 x86 为例，容易以偏概全。

面试题

Q1. x86 处理器采用的硬件内存模型通常被认为是：

单选题 · easy

  • A.完全顺序一致（SC）
  • B.总存储顺序（TSO）← 正确答案
  • C.宽松内存模型（Relaxed）
  • D.弱一致性（Weak）

答案：B。x86 采用 TSO，写操作经 FIFO 写缓冲按序提交，但允许 store-load 重排，它不是 SC，也不像 ARM 那样完全宽松。

Q2. sfence 指令的主要作用是：

单选题 · easy

  • A.强制所有之前的写操作提交到内存← 正确答案
  • B.强制所有之前的读操作完成
  • C.清空整个缓存
  • D.阻止 CPU 执行后续指令

答案：A。sfence 是存储屏障，保证之前的所有 store 在之后的 store 之前完成。就像后厨里的“清货口令”，先把做好的菜全部放进冷藏库。

Q3. 在 TSO 模型中，x86 允许发生哪种重排？

单选题 · easy

  • A.写-写重排
  • B.读-读重排
  • C.写-读重排（store-load）← 正确答案
  • D.读-写重排

答案：C。TSO 中 store 通过写缓冲按 FIFO 顺序提交，所以 store-store 不乱序；但后续 load 可以越过前面的 store 先执行，即 store-load 重排。

Q4. lfence 指令保证：

单选题 · mid

  • A.之前的所有写操作已完成
  • B.之前的所有读操作已完成← 正确答案
  • C.之后的所有读写已完成
  • D.所有缓存行同步到主存

答案：B。lfence 是加载屏障，确保之前的 load 指令全部完成，不影响 store。类比“取货口令”，先把要用的食材都搬到备料台。

Q5. 以下哪个内存顺序选项只保证原子性，不提供顺序保证？

单选题 · mid

  • A.memory_order_seq_cst
  • B.memory_order_acquire
  • C.memory_order_release
  • D.memory_order_relaxed← 正确答案

答案：D。relaxed 仅保证原子操作本身，其他线程观察到的顺序可能任意。acquire/release 提供配对的“先发生”关系，seq_cst 提供全局全序。

Q6. 以下哪些架构通常采用宽松内存模型？

多选题 · hard

  • A.ARM← 正确答案
  • B.x86
  • C.PowerPC← 正确答案
  • D.RISC-V← 正确答案

答案：ACD。ARM、PowerPC、RISC-V 属于宽松（弱）内存模型，允许更多重排；x86 是 TSO，写顺序较强。

Q7. 属于 x86 内存屏障指令的是：

多选题 · mid

  • A.mfence← 正确答案
  • B.lfence← 正确答案
  • C.sfence← 正确答案
  • D.dmb

答案：ABC。x86 提供 mfence/lfence/sfence；D 选项 dmb 是 ARM 的屏障指令，不是 x86 指令。

Q8. MESI 协议中，缓存行状态 E 表示：

单选题 · mid

  • A.该行已被修改
  • B.该行是唯一副本且与主存一致← 正确答案
  • C.该行被多个核心共享
  • D.该行无效

答案：B。Exclusive 表示当前核心持有唯一的缓存行副本，且与主存一致。Modified 表示已修改但主存不一致，Shared 表示多核共享，Invalid 表示失效。

Q9. 伪共享（False Sharing）的本质是：

单选题 · hard

  • A.多个线程真正共享同一个变量
  • B.多个线程访问不同变量，但它们位于同一缓存行← 正确答案
  • C.多个线程同时读共享变量
  • D.缓存行被错误映射到相同地址

答案：B。不同线程修改的是逻辑上无关的变量，但因为它们在同一个缓存行，每次写都会使对方缓存行失效。就像两位厨师各自改自己的调料瓶，却因为调料瓶放在同一个托盘上而频繁抢托盘。

Q10. 关于内存屏障对性能的影响，下列说法正确的是：

多选题 · hard

  • A.屏障会阻碍 CPU 乱序执行，造成流水线停顿← 正确答案
  • B.屏障数量越多，同步开销通常越大← 正确答案
  • C.在宽松内存模型中使用屏障可以获得所需顺序← 正确答案
  • D.内存屏障可以提高缓存命中率

答案：ABC。屏障会带来停顿和缓存同步开销，也能提供顺序保证，但不会提高缓存命中率。D 混淆了“缓存一致性”与“缓存命中率”的概念，屏障并不能让数据更大概率留在缓存中。