C# 的 ConcurrentStack 和 ConcurrentQueue 不是纯无锁，因高争用时会退化为 SpinWait 或 Monitor.TryEnter；其内部受限于 .NET 内存模型、GC 干预及缺乏双字原子操作，难以安全实现托管引用类型的 lock-free 队列。
为什么 C# 的 ConcurrentStack 和 ConcurrentQueue 不是纯无锁？
它们对外宣称“线程安全”，但内部在高争用或内存压力大时会退化为使用 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;
Node* oldHead;
do
{
oldHead = head;
newNode-youjiankuohaophpcnNext = 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等双字原子操作，无法规避 tail/head 不一致读>
因此，除非你控制整个生命周期（如对象池 + 手动内存管理 + unsafe + fixed 数组），否则不要尝试自己写托管无锁队列。
实际项目中该选什么？
绝大多数场景下，ConcurrentStack 和 ConcurrentQueue 是正确选择。它们在多数负载下表现接近无锁，且经过充分测试。只有当你明确观测到：Monitor.Enter 在性能剖析中成为瓶颈、且能接受 unsafe + 手动内存管理 + 仅限值类型 + 无 GC 干预时，才考虑手写。另外，.NET 6+ 的 Channel 在生产者/消费者模式下比手写无锁结构更可靠、更易维护。
真正容易被忽略的是：无锁 ≠ 更快。它只是消除了阻塞，但增加了缓存一致性流量（false sharing）、重试开销和实现复杂度。先用 dotnet-trace 确认锁确实是瓶颈，再决定是否踏入这个领域。
