C# 无锁数据结构方法 C#如何实现一个无锁队列

concurrentqueue 是首选，因其基于成熟 michael-scott 算法、经压测验证的生产级无锁队列，手写易出 aba、内存重排序、节点回收等隐蔽错误，且性能难超越、维护成本极高。

为什么 ConcurrentQueue<t></t> 是首选，而不是手写无锁队列

绝大多数场景下，你不需要自己实现无锁队列。.NET 自带的 ConcurrentQueue<t></t> 就是生产级无锁（lock-free）队列，底层基于 Michael-Scott 算法，使用 volatile 字段、Interlocked 操作和 CAS（CompareAndSwap）循环，已通过大量并发压测验证。

手写正确、高效、可维护的无锁队列极其困难：ABA 问题、内存重排序、GC 引用可见性、节点回收（如如何安全释放已出队节点）都会导致隐蔽崩溃或数据丢失。

• 调试难度高：错误常表现为偶发丢数据、死循环或 NULLReferenceException，且只在高并发下复现
• 泛型与 GC 交互复杂：.NET 的垃圾回收器不保证对象立即不可见，需配合 Unsafe.AsRef 或 MemoryBarrier 控制发布顺序
• 性能未必更好：ConcurrentQueue<t></t> 在 .NET Core 3.0+ 中已深度优化，自定义实现很难超越其吞吐量

如果真要手写，必须用 Interlocked.CompareExchange + 循环重试

无锁的核心是避免 lock，改用原子操作保障状态变更的线性一致性。关键不是“没锁”，而是“用硬件 CAS 替代互斥锁”。

以入队（Enqueue）为例，典型结构包含头尾指针（Node* head, Node* tail），每次操作都需：

• 读取当前 tail 值
• 构造新节点并设置其 next 为 null
• 用 Interlocked.CompareExchange(ref tail, newNode, oldTail) 尝试更新尾指针
• 失败则重读 tail，重试——这就是“乐观重试”模式

注意：不能直接赋值 tail = newNode，否则多线程下会覆盖彼此；也不能用 Interlocked.Exchange，它不检查前提条件，会破坏队列结构。

ConcurrentQueue<t></t> 的实际使用陷阱

它虽无锁，但行为和普通 Queue<t></t> 不完全一致，容易误用：

• TryDequeue(out T result) 返回 false 并不总意味着队列为空——可能只是当前线程没抢到出队权，需结合业务重试逻辑，而非直接抛异常
• 枚举器（foreach）是快照式遍历，不反映实时变化；且不保证线程安全（枚举中其他线程修改不会抛异常，但结果不可预测）
• 对引用类型，入队的是引用副本，若对象本身被多线程修改，仍需额外同步——无锁队列只保队列结构安全，不保元素内容安全
• 容量不受限，长期运行需监控内存，避免 OOM（没有 bounded 版本，不像 Java 的 LinkedBlockingQueue）

真正需要自研的少数情况及替代思路

仅当满足全部以下条件时，才考虑绕过 ConcurrentQueue<t></t>：

• 目标平台是 AOT 编译环境（如 unity IL2CPP），且 ConcurrentQueue<t></t> 因反射/泛型代码生成受限而无法使用
• 有硬性延迟要求（如微秒级 P99），且压测证明标准队列成为瓶颈（通常不会）
• 需要定制内存布局（例如对象池内节点复用、避免 GC 分配）

此时更稳妥的做法是复用成熟轮子，比如移植经过验证的 Agrona 中的 MpscArrayQueue（单生产者/多消费者）C# 绑定版，而非从零造轮子。自己写的无锁结构，哪怕跑通单元测试，也极大概率在真实负载下暴露内存模型缺陷。