c# Thread.MemoryBarrier 和 Interlocked.MemoryBarrier

来源:这里教程网 时间:2026-02-21 17:37:45 作者:

Thread.MemoryBarrier 和 Interlocked.MemoryBarrier 是同一个东西吗?

不是。它们在 .NET 中行为完全一致,但语义和使用意图不同:

Thread.MemoryBarrier()
强调线程执行顺序控制,
Interlocked.MemoryBarrier()
则明确服务于原子操作的内存可见性保障。两者底层都调用相同的 JIT 内存屏障指令(如 x86 的
mfence
),编译后生成的汇编也一样。

什么时候该用 Thread.MemoryBarrier 而不是 Interlocked.MemoryBarrier?

几乎不用。自 .NET Framework 2.0 起,

Thread.MemoryBarrier()
已被标记为过时(obsolete),文档明确建议改用
Interlocked.MemoryBarrier()
。虽然它仍能编译运行,但会触发编译警告
CS0618
,且在 .NET Core / .NET 5+ 中虽未移除,但已彻底失去存在必要。

Interlocked.MemoryBarrier()
是当前唯一推荐的全栅栏(full memory barrier)API
Thread.MemoryBarrier()
没有额外功能,也不更“轻量”——它和
Interlocked.MemoryBarrier()
性能、语义、生成代码完全相同
若你看到老代码里用了
Thread.MemoryBarrier()
,应直接替换,不需加任何条件判断

比 MemoryBarrier 更常用、更安全的替代方案有哪些?

绝大多数场景下,你根本不需要手写

MemoryBarrier
。现代 C# 提供了更高层次、更不易出错的同步原语:

volatile
字段修饰简单读写(如标志位),编译器会自动插入必要的读/写屏障
对整数等基本类型做原子更新,优先用
Interlocked.CompareExchange()
Interlocked.Increment()
等——它们自带 full barrier 语义
跨线程传递对象引用或复杂状态,用
ConcurrentQueue<t></t>
BlockingCollection<t></t>
Channel<t></t>
需要强顺序保证时,考虑
SpinLock
Monitor
(锁本身隐含 acquire/release 语义)

手动插

Interlocked.MemoryBarrier()
容易错位:放太早没效果,放太晚破坏逻辑,还可能掩盖真正的竞态根源。

为什么 Interlocked.MemoryBarrier 不带参数,而有些语言有 Read/Write/SeqCst 区分?

.NET 的

Interlocked.MemoryBarrier()
是 full barrier,等价于其他平台的
memory_order_seq_cst
。它不提供弱序选项(如
memory_order_acquire
),因为:

JIT 和 CLR 运行时未暴露细粒度内存序 API(不像 C++ 的
std::atomic_thread_fence
多数托管代码无需极致性能优化;full barrier 开销在现代 CPU 上可忽略 避免开发者误选弱序导致难以复现的内存可见性 bug

如果你真需要 acquire/release 语义,只能退回到 unsafe +

Thread.VolatileRead
/
Thread.VolatileWrite
(仅限 .NET Framework)或依赖
volatile
字段——但这些依然不如用
Interlocked
方法组合来得清晰可靠。

bool _ready = false;
object _data = null;
<p>// ❌ 错误:无同步,_data 可能在 _ready = true 前就对其他线程可见(重排序)
_ready = true;
_data = new object();</p><p>// ✅ 正确:用 Interlocked 写入 + barrier 保证顺序和可见性
_data = new object();
Interlocked.MemoryBarrier(); // 确保 _data 初始化完成后再让 _ready 生效
_ready = true;</p><p>// ✅ 更推荐:用 volatile 字段(简洁且语义明确)
private volatile bool _ready2;
private object _data2;
// ...赋值时只需:
_data2 = new object();
_ready2 = true; // volatile write 自动带 release 语义</p>

真正难的从来不是加一个

MemoryBarrier
,而是判断「这里到底要不要加」以及「加在哪儿才对」——大多数时候,答案是:别加,换更高级的抽象。

相关推荐