Thread.MemoryBarrier() 仅阻止CPU重排序，不防止编译器/JIT重排；需用volatile字段或Volatile.Read/Write实现完整三级顺序约束。
MemoryBarrier 为什么不能防止编译器重排序
Thread.MemoryBarrier() 只对 CPU 级内存访问起作用，它插入的是一个「全内存屏障」（full memory barrier），影响的是处理器的 Load/Store 执行顺序和缓存可见性，但完全不干预 C# 编译器（Roslyn）或 JIT 编译器的指令重排。也就是说，Thread.MemoryBarrier() 调用前后的变量读写仍可能被 JIT 优化成不同顺序——尤其在 Release 模式下。
常见错误是以为加了 Thread.MemoryBarrier() 就能“锁住所有顺序”，结果发现字段赋值还是被提前或延后了。真正需要禁止编译器/JIT 重排时，得靠 Volatile.Read/Volatile.Write 或 volatile 字段修饰符。
volatile 字段 vs Volatile.Read/Write 的区别
两者都提供编译器 + JIT + CPU 三级重排序约束，但语义和适用场景不同：
-
volatile字段修饰符：适用于长期生命周期的字段，强制每次读写都带 acquire/release 语义，开销略高，但写法最简洁 -
Volatile.Read(ref int)和Volatile.Write(ref int, value)：适合临时、单次、非字段场景（比如栈变量引用、Span元素），避免定义字段，也支持泛型参数 - 注意：
Volatile.Read对int是 acquire 语义，Volatile.Write是 release 语义；组合使用才能构成完整的 acquire-release 同步对
MemoryBarrier 在什么场景下仍然有用
当你要显式控制两个非 volatile 内存操作之间的顺序，且已确保编译器/JIT 不会乱动（比如用 volatile 字段兜底后，再补一道 CPU 屏障），Thread.MemoryBarrier() 才有明确意义。典型用例：
- 实现无锁队列时，在更新 tail 指针前确保所有节点数据已写入完成（配合
Volatile.Write使用） - 手动实现双重检查锁定（Double-Check Locking）中的初始化完成标志位同步
- 与非托管内存（如
Unsafe.AsRef访问的 native buffer）交互时，需绕过 .NET 的 volatile 规则，靠MemoryBarrier强制刷新 CPU 缓存行
单独调用 Thread.MemoryBarrier() 几乎从不推荐——它太底层、易误用，且 .NET 6+ 中已被标记为 [Obsolete]，建议优先用 Volatile 类型方法。
容易被忽略的 JIT 优化点：局部变量和 inlining
即使你用了 volatile 字段，JIT 仍可能把整个方法内联，并在内联后重新分析并重排逻辑。例如：
public void Publish() {
_ready = true; // volatile field
Thread.MemoryBarrier(); // 这行可能被 JIT 判定为冗余而删掉
}更稳妥的方式是让关键读写直接绑定到 volatile 字段，避免中间变量或屏障孤立存在：
Volatile.Write(ref _state, 1); Volatile.Write(ref _ready, true); // 两步都用 Volatile.Write，语义清晰、不可省略
另外，MethodImplOptions.NoInlining 可禁用内联，但代价是性能损失，仅用于调试验证。
