内存屏障是软件向硬件发出的执行顺序约束请求，通过触发CPU内存一致性协议和流水线控制来确保屏障前后特定类型内存访问的顺序性，而非阻止乱序执行。
内存屏障（Memory Barrier，也称内存栅栏）本身不是硬件指令，而是软件向硬件发出的执行顺序约束请求。它不“阻止”乱序执行，而是要求硬件在屏障前后维持特定的内存访问顺序语义——这是通过触发 CPU 的内存一致性协议和流水线控制机制来实现的。
内存屏障的本质是向硬件传递顺序承诺
CPU 为提升性能，默认允许以下乱序行为：
- 写操作之间重排（Store-Store）
- 读操作之间重排（Load-Load）
- 读后写重排（Load-Store）
- 写后读重排（Store-Load，x86 中较严格，ARM/RISC-V 中常见）
当编译器或程序员插入 MemoryBarrier()（如 x86 的 mfence、ARM 的 dmb ish），实际效果是：
- 让 CPU 暂停后续某些类型的内存操作，直到屏障前的指定类型操作全部完成（对 cache、store buffer、invalidation queue 等结构产生可见影响）
- 强制刷新 store buffer（对 StoreStore/StoreLoad 屏障关键）
- 同步 invalidate queue 或等待缓存一致性消息回传（对 LoadLoad/LoadStore 屏障关键）
- 禁止编译器和 CPU 跨越屏障重排满足约束条件的访存指令
不同屏障类型对应不同硬件动作
以 ARMv8 和 x86 为例：
-
LoadLoad 屏障（如
lfence/dmb ishld）：确保屏障前的读操作返回结果后，才开始执行屏障后的读操作；硬件会阻塞后续 load 进入加载队列，直到前面所有 load 完成数据返回 -
StoreStore 屏障（如
sfence/dmb ishst）：确保屏障前的写已提交到 store buffer 并（按需）写入 L1d cache；部分架构还会清空 store buffer 中靠前的条目 -
Full barrier（如
mfence/dmb ish）：兼具 LoadLoad + LoadStore + StoreStore 效果；x86 的mfence还隐式序列化 store buffer —— 即等待所有之前 store 对其他核可见后，才放行后续访存
硬件真正“生效”的关键路径
屏障效果依赖于底层微架构组件协同，典型路径包括：
- Store Buffer 控制：屏障指令使 CPU 暂停向 store buffer 写入新 store，或强制将 buffer 中已有 store 刷出到 cache/coherence domain
- Invalidation Queue 同步：多核场景下，屏障可能触发等待 pending 的 cache line 失效确认（I→Invalid），保证后续 load 不读到过期副本
- TLB / Cache Line 状态检查：某些屏障会隐式等待 TLB 更新或 cache line 回写完成，避免地址翻译与数据访问错序
- 执行单元调度干预：超标量 CPU 的调度器收到屏障信号后，会清空相关依赖链，拒绝将屏障后指令提前发射（尤其针对有 memory dependency 的指令）
注意：屏障不能替代原子操作，也不保证全局时间顺序
内存屏障只约束当前 CPU 核上指令的执行观测量级顺序，它：
- 不保证其他核立刻看到你的写（仍需 cache coherency 协议如 MESI，屏障只是配合它）
- 不提供原子性（如 read-modify-write 需用
lock xchg或ldxr/stxr） - 不能防止编译器优化（需搭配 volatile / compiler barrier 或 C++
std::atomic_thread_fence） - 过度使用会显著降低性能——因它打断流水线、阻塞执行单元、增加 cache 压力
