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<t></t>元素），避免定义字段，也支持泛型参数 注意：
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可禁用内联，但代价是性能损失，仅用于调试验证。
