c# 如何用C#实现一个无锁(Lock-Free)的栈或队列

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

为什么 C# 的
ConcurrentStack<t></t>
ConcurrentQueue<t></t>
不是纯无锁?

它们对外宣称“线程安全”,但内部在高争用或内存压力大时会退化为使用

SpinWait
甚至轻量级锁(如
Monitor.TryEnter
),并非严格意义上的 lock-free。真正的 lock-free 要求:任意线程被挂起、终止,都不影响其他线程继续完成操作(即满足 wait-free 或至少 lock-free 的 progress guarantee)。C# 运行时和 .NET 内存模型对无锁编程的支持有限,尤其涉及 GC 和引用类型时,
CompareExchange
对对象引用的 ABA 问题无法靠硬件指令直接解决。

Interlocked.CompareExchange
实现 lock-free 栈(仅限值类型)

这是最可控的起点。栈的 push/pop 只需原子更新头指针,适合用单个字段 + CAS 模拟。但必须避免 ABA —— 对值类型(如

int
long
)可借助“带版本号的指针”(如
long
高 32 位存版本,低 32 位存地址),但 .NET 不支持原生双字 CAS(
Interlocked.CompareExchange128
仅 Windows x64 且不支持托管引用)。所以实用方案是:只对值类型实现,或接受一定 ABA 风险(在低并发、短生命周期场景下可接受)。

定义节点结构体:
struct Node { public T Value; public Node* Next; }
(需
unsafe
头指针用
Node*
类型的字段,初始为
null
push:读当前
head
→ 构造新节点 →
Interlocked.CompareExchange(ref head, newNode, oldHead)
循环直到成功
pop:同理,读
head
→ 若非空则用
CompareExchange
尝试更新为
head->Next
unsafe
{
    Node* head = null;
    Node* newNode = stackalloc Node[1];
    newNode->Value = value;
<pre class='brush:php;toolbar:false;'>Node* oldHead;
do
{
    oldHead = head;
    newNode->Next = oldHead;
} while (Interlocked.CompareExchange(ref head, newNode, oldHead) != oldHead);

}

托管引用类型下的无锁队列为何极难安全实现?

队列需要两个指针(head/tail),必须保证二者协同更新的原子性。CAS 单指针无法避免“tail 已前进但 head 未更新”的中间态被其他线程误读。Michael-Scott 队列算法虽经典,但在 .NET 中面临三个硬伤:

GC
可能在 CAS 成功后、新节点被其他线程读取前回收该节点(需
GCHandle.Alloc
固定,但开销大且易泄漏)
引用类型的 ABA:节点 A 被弹出 → 内存复用 → 新节点 A' 分配在同一地址 → CAS 误判为“仍是原 A” .NET 没有
atomic<pair int>></pair>
等双字原子操作,无法规避 tail/head 不一致读

因此,除非你控制整个生命周期(如对象池 + 手动内存管理 +

unsafe
+
fixed
数组),否则不要尝试自己写托管无锁队列。

实际项目中该选什么?

绝大多数场景下,

ConcurrentStack<t></t>
ConcurrentQueue<t></t>
是正确选择。它们在多数负载下表现接近无锁,且经过充分测试。只有当你明确观测到:
Monitor.Enter
在性能剖析中成为瓶颈、且能接受 unsafe + 手动内存管理 + 仅限值类型 + 无 GC 干预时,才考虑手写。另外,.NET 6+ 的
Channel<t></t>
在生产者/消费者模式下比手写无锁结构更可靠、更易维护。

真正容易被忽略的是:无锁 ≠ 更快。它只是消除了阻塞,但增加了缓存一致性流量(false sharing)、重试开销和实现复杂度。先用

dotnet-trace
确认锁确实是瓶颈,再决定是否踏入这个领域。

相关推荐