内存屏障真正约束的是访存重排类型（Store-Store、Load-Load、Load-Store、Store-Load），通过协调store buffer、invalidation queue、缓存状态等硬件模块，确保屏障前的内存操作对屏障后的操作可见，而非禁止乱序执行本身。
内存屏障不是“阻止乱序执行”的开关，而是向硬件和编译器发出的明确顺序承诺：它不禁止乱序本身，而是在关键位置划定边界，确保某些内存操作在逻辑上必须先完成、再可见。
内存屏障真正约束的是什么
现代 CPU 为提升性能，默认允许四类访存重排：
- 写-写重排（Store-Store）：两个写操作顺序可调
- 读-读重排（Load-Load）：两个读操作可并行或换序
- 读-写重排（Load-Store）：读操作可能被提前到写之前
- 写-读重排（Store-Load）：最宽松的一类，尤其在 ARM/RISC-V 上常见
内存屏障的作用，就是针对其中一类或多类，强制建立“屏障前的操作必须对屏障后的操作可见”这一语义。它不冻结整个流水线，只干预与内存一致性相关的路径，比如 store buffer 刷出、invalidation queue 同步、缓存行状态确认等。
不同屏障类型对应的关键硬件动作
以 x86 和 ARMv8 为例，每种屏障触发不同的微架构响应：
- LoadLoad 屏障（如 lfence / dmb ishld）：阻塞后续 load 进入加载队列，直到前面所有 load 返回有效数据
- StoreStore 屏障（如 sfence / dmb ishst）：确保屏障前的 store 已进入 store buffer 并提交到 L1d cache；部分实现会清空 buffer 中靠前条目
- Full 屏障（如 mfence / dmb ish）：兼具 LoadLoad、StoreStore 和 LoadStore 效果；x86 的 mfence 还隐式序列化 store buffer，即等待所有前置 store 对其他核可见后才放行后续访存
屏障生效依赖底层组件协同
它的效果不是单靠一条指令完成，而是通过协调多个硬件模块来落地：
- Store Buffer 控制：屏障指令让 CPU 暂停向 store buffer 写入新 store，或强制刷出已有内容
- Invalidation Queue 同步：多核场景下，可能触发等待 pending 失效确认（I→Invalid），避免后续 load 读到过期副本
- TLB 与缓存行状态检查：某些屏障隐式等待 TLB 更新或 cache line 回写完成，防止地址翻译与数据访问错序
- 执行单元调度干预：超标量 CPU 的调度器收到屏障信号后，会限制后续内存指令的发射时机
为什么不能只靠编译器 barrier()
像 __asm__ __volatile__("" ::: "memory") 这类编译器屏障，仅阻止编译器重排，对 CPU 硬件乱序完全无效。它不生成任何 CPU 指令，也不影响 store buffer 或缓存一致性协议。真实并发场景中，必须配合硬件级屏障（如 mfence、dmb）才能保障跨核可见性。例如生产者-消费者模型里，仅用编译器 barrier() 无法防止 obj.ready=1 被 CPU 提前于 obj.data=100 执行并对外可见。
