volatile 字段读写自带隐式内存屏障，但仅限于该字段本身
当你声明
volatile bool _isRunning，每次对它的读（
_isRunning）或写（
_isRunning = true）都会自动插入对应语义的内存屏障：读是 acquire-fence，写是 release-fence。这意味着—— 写操作前的所有内存访问（如给
data赋值）不会被重排到该写之后； 读操作后的所有内存访问不会被重排到该读之前。
但它不保证其他变量的可见性。比如：
volatile bool _ready = false;
int _value = 0;
<p>// 线程A
_value = 42;
_ready = true; // ✅ _ready 写入带 release-fence</p><p>// 线程B
while (!_ready) { } // ✅ _ready 读取带 acquire-fence
Console.WriteLine(_value); // ❌ 可能输出 0！因为 _value 不是 volatile，也不受屏障“保护”这里
_value的写入仍可能被编译器/CPU乱序到
_ready = true之后，或者线程B看到
_ready更新了，却还没从缓存同步到
_value的新值。
Interlocked.MemoryBarrier 是显式全屏障，作用范围更广但开销略高
Thread.MemoryBarrier()（底层调用
Interlocked.MemoryBarrier）是一条完整的双向屏障：它强制屏障前的所有读写完成并对其它线程可见，且屏障后的所有读写不得提前执行。 它不绑定任何变量，是“全局生效”的指令级约束； 适用于需要跨多个非 volatile 字段建立 happens-before 关系的场景； 性能比单纯 volatile 读写略低（实测约慢 1.5–2 倍），但远快于
lock。
修复上面的例子只需加一道屏障：
// 线程A
_value = 42;
Thread.MemoryBarrier(); // ✅ 强制 _value 写入完成并可见
_ready = true;
<p>// 线程B
while (!_ready) { }
Thread.MemoryBarrier(); // ✅ 强制后续读取能看到所有之前写入
Console.WriteLine(_value); // ✅ 现在一定输出 42别混用 volatile 和 Interlocked.MemoryBarrier 在同一字段上
这是常见误区：以为 “volatile + MemoryBarrier” 更安全，其实多余甚至有害。
volatile字段的读/写已含对应语义的屏障，再手动插
Thread.MemoryBarrier()属于重复同步，徒增开销； 更严重的是，
Interlocked.MemoryBarrier不能用于
volatile字段的引用传参（C# 编译器禁止将 volatile 字段以
ref方式传递）； 若你真需要原子读-改-写（如
++、条件赋值），直接用
Interlocked.Increment或
Interlocked.CompareExchange—— 它们内部已含完整屏障，且保证原子性。
什么时候该选哪个？看操作目标和语义需求
简单说：
只读/只写一个标志位（如IsStopping、
HasData），用
volatile—— 轻量、够用、语义清晰； 要确保「某组变量」的写入顺序和可见性（如先设状态再更新缓冲区），用
Thread.MemoryBarrier()； 要修改值（计数、交换、条件更新），必须用
Interlocked.*方法 —— 它们既原子又带屏障，
volatile对这类操作完全无效（
++永远不是原子的）。
最易被忽略的一点：volatile 解决不了竞态条件（race condition）。比如两个线程同时执行
if (!_isAuthenticated) Authenticate();，即使
_isAuthenticated是 volatile，仍可能双双进入认证逻辑。这种时候，
Interlocked.CompareExchange或
lock才是正解。
