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# 绑定版，而非从零造轮子。自己写的无锁结构，哪怕跑通单元测试，也极大概率在真实负载下暴露内存模型缺陷。
