无锁MPSC队列实战：用.NET原生内存打造零GC高吞吐队列

多线程程序里，最容易被低估的组件往往是那个看起来不起眼的队列。前阵子我调一个网络收包管道的抖动问题：12 个连接线程往同一个队列里塞请求 payload，下游一个消费线程负责批量处理，最初用的是 ConcurrentQueue<T>，流量一上来，GC 和延迟抖动成对出现。后来我换成了自己写的 ConcurrentNativeQueue<T>——一个使用 .NET 实现、节点分配在原生内存里的无锁 MPSC（多生产者、单消费者）队列，队列自身分配为 0，抖动基本消失。

这篇文章把设计思路、关键代码、踩坑记录从头到尾说清楚。适合正在为高吞吐日志管道、网络包分发、命令总线或任何“多线程写、单线程读”场景找方案的 .NET 开发者，也适合想理解无锁队列到底怎么落地的人。

1. 先说破场景：什么情况下你非 MPSC 队列不可

1.1 线程拓扑图和队列的角色

MPSC 拆开就是 Multi-Producer Single-Consumer：生产者可以有多个，消费者必须只有一个。这个拓扑在业务代码里极其常见。比如一个接入服务，十几个连接线程各自收到请求，都要把原始数据丢给同一个后台线程做聚合、落盘或转发；再比如游戏里的输入事件，多个玩家操作线程产生命令，一个逻辑线程统一处理；还有日志管线，多个业务线程打点，一个独立线程负责格式化、批量化写文件。

这类场景共同的特点是：写端天然并发，读端却只想要一份串行视图。消费者本来就是单线程在跑，那它就不需要参与任何队列级别的原子竞争，这是 MPSC 队列性能远高于 MPMC（多生产者多消费者）队列的根本原因。

判断标准其实很直接：如果消费者线程你数得出只有一个，并且生产者的数量可能继续增长，那 MPSC 就是天然匹配。反过来说，如果消费者也需要并行处理，或者你不想承担多消费者分摊逻辑，那就别硬套 MPSC，换 MPMC 或者分区队列更合适。

1.2 ConcurrentQueue 和 Channel 在哪一环不够用

ConcurrentQueue<T> 是一个 MPMC 通用队列，入队出队都要处理多线程竞争。它很稳，但在单消费者场景里浪费了大量能力。最明显的一点是，消费者每次取一个元素都要出现 CAS 级别的原子操作，而且取不出批量数据；底层分段数组扩容时也会分配托管节点，GC 压力实实在在地存在。

Channel<T> 是面向异步流式管道设计的，支持背压、支持 async/await，单读单写下非常顺手。但它的核心目标不是原生内存和零分配，UnboundedChannel 在持续入队时同样会有动态管理和分配开销。如果你不需要异步等待、不需要背压，只是想把高频消息从多个线程安全地递给一个消费线程，那它就不是最优解。

我这么说不是要否定这两个类。它们都是非常优秀的通用组件，只是目标不匹配。当你面对的是每秒几十万甚至上百万条消息的写入需求，而你已经在用性能剖析工具确认了分配和锁竞争是瓶颈时，就该考虑一个为这种拓扑优化的专用队列。

1.3 适用与不适用清单

适合使用这个队列的场景：

• 多线程写入、单线程消费的事件总线或命令队列
• 网络收包、日志聚合、遥测数据流水线
• 对延迟抖动敏感，要求可预测性的实时处理链路
• 消息主体本身就是值类型数据，比如结构体、定长 buffer、指针包裹

不适合使用的场景：

• 需要多个消费者并行处理消息
• 需要直接配合 async/await 消费流程，希望队列提供背压语义
• 消息类型是引用类型且不方便改造为 unmanaged 结构
• 项目组无法承担原生内存手动管理带来的内存安全责任

最后一条尤其要说清楚：这份性能是用内存所有权换来的。队列只为你管理节点内存，不为你管理 T 里可能包含的外部资源。如果你的 T 里藏着一个需要手动释放的句柄，那释放时机得你自己设计。

2. 结构定生死：原生节点、哨兵与缓存行隔离

2.1 一个 Node 长什么样

要实现“零 GC 压力”，第一件事就是让队列的节点不进入 GC 堆。做法是把节点分配在原生内存里，也就是 NativeMemory.Alloc 或 Marshal.AllocHGlobal 拿到的非托管内存。节点本身长这样：

csharp复制[StructLayout(LayoutKind.Sequential)]
private unsafe struct Node
{
    public T Value;
    public Node* Next;
}

T 必须保证是 unmanaged 类型。这样 Node 就是一块连续的、自包含的内存，Value 直接内嵌在节点里，而不是引用一个托管对象。整条链表由指针串起来，GC 完全看不见它的存在，自然也不用管它的年轻代晋升和回收。

为什么不能直接存托管引用？因为 GC 在压缩回收时需要更新所有对象引用，但它无法感知原生内存里存放的引用位置。一旦被 GC 移动了对象，这份引用就成了悬空引用，轻则读取到错误数据，重则进程崩溃。这个问题后面单独展开，先记住结论：这个队列在 API 层面就要求 where T : unmanaged。

在构造函数里，队列不会每次 Enqueue 都去 AllocHGlobal，那样会产生系统调用和内存碎片。正确做法是预先准备一个原生节点池，一次分配一大块，之后入队从池里取节点、出队把节点还回去。池里维护空闲链表，取和还都是指针操作。

2.2 为什么需要哨兵节点

空队列的判断比想象中难办。如果你直接用 head == tail 判断空，在多生产者入队时会看到大量误判：tail 已经被某个生产者换成了新节点，但新节点还没有链到前一个节点的 Next 上，消费者这边 head 还停在原处，一比，两者明显不等，可队列里其实又没有“可见”的数据。

引入哨兵节点之后，问题就简单了。head 永远指向一个已经消费完的节点，真正待消费的数据是 head->Next 指向的内容。于是，队列是否为空的判定就收敛成一句话：

text复制队列为空  ⇔  head->Next == null

这样消费者不需要读 tail 也能判断空，省掉一次共享变量访问。哨兵节点本身不保存有意义的数据，它的唯一职责是给链表一个稳定的起点。入队时，新节点被挂在链尾；出队时，head 向前移动，但永远不会越过一个 Next 为 null 的节点。

有个细节容易被忽略：当队列被读到只剩最后一个节点时，这个节点会成为新的哨兵，不能归还给池。因为它还在 tail 的位置上，下一个生产者可能正准备往它的 Next 上挂新节点。如果消费者图省事把它释放了，后续生产者一旦写入就是访问野指针。

2.3 head 和 tail 为什么要各占一条缓存行

head 和 tail 是两个被完全不同线程触碰的变量：head 几乎只被消费者读取和移动，tail 则天天被生产者们争抢。在现代多核 CPU 上，缓存行是内存操作的最小粒度，一般来说是 64 字节。如果 head 和 tail 恰好落在同一个缓存行里，那么每次消费者更新 head，都会让所有生产者拿起该缓存行时被迫重新同步；每次生产者原子交换 tail，也会把消费者的缓存行弄脏。结果就是两边互相拖累，表现为无锁代码却持续出现跨核缓存同步流量。

解决办法很简单：给它们各自铺满一个缓存行。

csharp复制private unsafe struct PaddedPtr
{
    public nint Value;
    public fixed byte Padding[64];
}

字段声明就变成：

csharp复制private PaddedPtr _head;
private PaddedPtr _tail;

实际使用的时候操作 _head.Value 和 _tail.Value。千万别小看这个 padding，我在一台双路服务器上做过对比，加 padding 和不加 padding 的吞吐差距能到 10% 到 15%，几乎是零成本白捡的优化。这也是所有认真实现的无锁队列都会做的一件事。

3. 入队是唯一竞争点：Exchange 之后再释放写

3.1 三步式入队的过程拆解

入队操作是整个队列里唯一的全局竞争点，但它不需要 CAS 重试循环，只需要一个原子交换。核心代码不长：

csharp复制public unsafe bool TryEnqueue(in T item)
{
    Node* node = _pool.Rent();
    node->Value = item;
    node->Next = null;

    Node* prev = (Node*)Interlocked.Exchange(ref _tail, (nint)node);
    Volatile.Write(ref prev->Next, node);

    return true;
}

步骤拆开看：

第一步，从原生节点池里拿一个空闲节点，把 T 的值写进去，把 Next 置空。这里有个顺序要求：写 Value 必须在把这个节点暴露给消费者之前完成，否则消费者可能读到一个半初始化状态。

第二步，Interlocked.Exchange 把新节点设置成队尾，同时拿回原来的旧队尾。这个操作对全局是原子的，所有生产者同时调用也只会有一个人拿到某个特定的旧队尾，其他人分别拿到各自对应的前驱。

第三步，把新节点挂到旧队尾的 Next 上。这一步必须用 Volatile.Write，它带 release 语义，保证消费者在看到 Next 更新之后，一定也能看到此前写入的 Value。

3.2 不可见窗口与线性化点

细心的读者会发现一个问题：消费者可能在 Interlocked.Exchange 之后、Volatile.Write 之前去读旧队尾的 Next，此时它会看到 null，误以为队列是空的。这就是所谓的暂时不可见窗口。

这不是 bug，而是这个算法的线性化点被定义在“旧队尾的 Next 完成 release 写”这个位置。也就是说，一次 Enqueue 严格的“生效时刻”不是 Exchange，而是 Next 写入完成。窗口极小，通常只有几十个纳秒，而且下一条入队消息或者消费者的下一次重试很快就会让数据暴露出来。

大多数业务场景都能接受这种短暂不可见。如果你需要一个“调用 Enqueue 返回后，消息立刻可以被消费者看到”的严格语义，那就需要在尾节点上做 marker 翻转，算法会复杂不少。我建议先确认需求，不要为理论上的“完美”增加复杂度。

3.3 为什么这里不需要 CAS 循环

很多人第一次看到 Interlocked.Exchange 版本会觉得奇怪：多个生产者同时入队，明明有一个共享的 tail，为什么不做 CompareExchange 循环？

关键在于，Exchange 直接把“抢占某个旧队尾”这件事原子完成了。每个生产者拿到的 prev 一定只属于它自己：A 线程先 Exchange，拿走 tail1，B 线程再 Exchange，拿到的就是 A 的新节点。每个生产者只往自己拿到的 prev 的 Next 上写一次，互不干扰，所以不需要失败重试。

CAS 循环适合那种“必须满足某个条件才更新”的场景，比如从一个栈里把某个节点安全地摘出来。而尾插队列里，我们只是想把新节点变成新的 tail，同时带出旧 tail，Exchange 一步就能完成。

这个设计还有一个附带好处：入队路径没有任何自旋等待，生产者线程只要执行几个原子操作就能结束，不会在队列竞争激烈时出现线程被卡住的情况。

4. 出队是本地操作：TryDequeue 与 DrainTo 的批量优势

4.1 TryDequeue 的最小逻辑

消费者的代码非常简单，因为它没有任何原子竞争：

csharp复制public unsafe bool TryDequeue(out T item)
{
    Node* head = (Node*)Volatile.Read(ref _head);
    Node* next = Volatile.Read(ref head->Next);

    if (next == null)
    {
        item = default;
        return false;
    }

    item = next->Value;
    Volatile.Write(ref _head, (nint)next);
    _pool.Return(head);
    return true;
}

这段代码体现出来的速度感，和 ConcurrentQueue 拉开差距的地方就是“没有竞争”：消费者只读自己的 head，顺着 head 的 Next 取数据，再把 head 前移一位，全程不需要 CAS，不需要和生产者争夺任何共享锁或原子状态。

为什么可以安全释放旧的 head？因为消费者观察到 head->Next != null 时，说明生产者的 Volatile.Write 已经完成，它不会再往这个 head 的 Next 上写任何东西。这个节点的生命周期已经结束了，归还给池是合法的。

如果 next 恰好是当前 tail，说明队列已经读完。这时 next 变成本地的新哨兵，等待下一个生产者把新消息挂上来。整个移 head 的过程，把“空队列”的判断自然延续下去，非常干净。

4.2 DrainTo：一次遍历搬走 N 条

TryDequeue 每次只取一条，在高吞吐场景下有点浪费。单消费者还有一个更痛快的玩法：沿着 Next 一次抓一串节点，搬进调用方预先准备好的 Span 里。这就是 DrainTo：

csharp复制public unsafe int DrainTo(Span<T> buffer)
{
    Node* current = (Node*)Volatile.Read(ref _head);
    int count = 0;

    while (count < buffer.Length)
    {
        Node* next = Volatile.Read(ref current->Next);
        if (next == null) break;
        buffer[count++] = next->Value;
        current = next;
    }

    Node* oldHead = (Node*)Volatile.Read(ref _head);
    Node* walk = oldHead;
    while (walk != current)
    {
        Node* toReturn = walk;
        walk = Volatile.Read(ref walk->Next);
        _pool.Return(toReturn);
    }

    Volatile.Write(ref _head, (nint)current);
    return count;
}

调用方可以一次性腾出 64 个或 128 个槽位的 Span，消费者在循环里批量搬移。链表的节点不需要排序、不需要锁定、不需要分多次尝试，一次 volatile read 就能顺着指针跑下去。

这就是 MPSC 最有吸引力的地方：批量消费的能力几乎是免费的。实际效果是，单条取出和批量取出 128 条之间的吞吐差异经常可以达到一两倍，因为每次内存屏障的开销被平摊到了大量消息上。

4.3 释放节点的安全条件

批量搬移之后，释放哪些节点、保留哪些节点，是容易写错的地方。原则是：current 之前的全部释放，current 本身保留。

如果 buffer 装满了，current 可能并不是队尾，它后面还有数据等待下一次 DrainTo 来取。这时释放 current 会导致链表断掉。如果队列真的空了，current 就是新的哨兵，同样不能释放。

再看并发视角：生产者是否会往 oldHead 上写 Next？不会。oldHead 的 Next 要么已经非空，要么在消费者观察的瞬间还是 null。如果是后者，说明它现在就是队尾，那消费者会在 current 上停下，不会把它当成待释放节点。一旦消费者看到某个节点的 Next 非空，写入这个 Next 的生产者就已经完成了它对这个节点的所有操作，所有权才真正交回到消费者这边。

这个所有权转移模型是整个队列安全性的地基，理解了它，后面的内存回收才不会有问题。

5. 零 GC 不是口号：承诺边界与验证方法

5.1 T 必须是 unmanaged 的原因

为什么这个队列限死 where T : unmanaged，前面已经提到过核心原因：GC 无法追踪原生内存里的引用。

GC 在标记阶段要遍历所有托管对象引用，它只能看见托管堆中的字段、数组元素、局部变量、静态字段，看不到指针指向的原生内存里存放了什么。如果你的 Node 写在非托管内存里，里面却塞了一个 string 引用，GC 既不会因为这个引用而保持对象存活，也不会在对象移动时修正这个字段的值。结果就是：string 可能被回收，或者 GC 把 string 搬走之后，原生内存里的旧引用还指向原来的地址，读出来全是垃圾。

另外，C# 的指针类型本就不允许指向含有托管引用字段的结构体。因此 where T : unmanaged 不只是一个优化策略，更是一条安全红线。

如果你的消息不是 unmanaged，比如包含字符串或对象，那在入队之前先想办法把它展平成值结构，比如定长字节缓冲区、长度字段、枚举状态等。实在要传引用类型，那就别硬用原生队列，老老实实回到托管队列的怀抱。

5.2 队列自己的分配都去哪儿了

传统队列的最大隐藏成本，是你的高并发写路径上不断产生新对象。ConcurrentQueue 内部有分段数组，入队时如果当前段满了会 new 新的数组；Channel 的 Unbounded 模式底层也有动态增长。这些分配都要进入 GC 的年轻代，年轻代一满就要触发收集，收集时如果你的消费线程还在持续工作，就会出现停顿。

这个原生队列把所有节点分配都挪到了构造函数阶段。队列初始化时，一次性从原生内存里分配一批节点，之后每次入队只是从空闲链表摘一个节点，出队时还回去。整个运行过程中，入队和出队路径不产生新的托管对象，不触发 GC 分配，自然也就不会因为队列自身的行为往请求线程里引入收集压力。

需要澄清的是，“队列自身零分配”不等于“整个进程零 GC”。如果你在消费线程里写日志字符串、用 LINQ 拼接、闭包捕获变量，那些分配依然存在。零 GC 压力是一个局部承诺，要求整条处理链路都有意识地去控制分配，才能把 GC 停顿从关键路径上摘除。

5.3 用 GetAlocatedBytes 验证 0 分配

聊“零分配”不能只靠感觉，要有一组可复现的数据。最简单的验证方式是用 .NET 提供的线程分配计数：

csharp复制long before = GC.GetAllocatedBytesForCurrentThread();

for (int i = 0; i < 1_000_000; i++)
{
    queue.TryEnqueue(new Packet(...));
}

long after = GC.GetAllocatedBytesForCurrentThread();
long allocated = after - before;

没有工具链的时候，这一段代码就能判断队列是否引入托管分配。allocated 应当是 0，或者只有你确认的可接受噪声。配合 BenchmarkDotNet 的 MemoryDiagnoser 可以更正式地记录 Allocated 列，但基本思路是一样的。

我踩过一个很隐蔽的分配：入队时为了统计队列深度调用了某个委托，委托捕获了外部变量，每次调用都产生一个闭包对象。排查半小时才用 GetAllocatedBytesForCurrentThread 定位到。所以验证分配时，千万不要只测一次两次，要有百万级迭代和前后差分。

6. 回望真坑：ABA、弱内存序和 native memory 所有权

6.1 危而不显的 ABA 问题

无锁算法最常见的中招方式就是 ABA。场景是这样的：线程 A 读到一个节点 N，准备做 CAS；线程 B 先把 N 摘走，之后又把某个节点放回原位，巧合的是放回来的还是 N；线程 A 的 CAS 这时成功，但它以为“状态没变过”，实际上链表结构早已面目全非。

主链上的队列入队出队不会出现 ABA，因为一个节点一旦从队头被消费，就不会再插回队头。出队后节点会被归还到空闲池，之后可能被新的生产者重新取走、重新链入队尾。问题就出在空闲池：如果节点池是无锁 Treiber Stack，同一个节点被反复 push/pop，就可能触发 ABA。

规避方式有很多，最简单的工程化方案是让归还池只发生在消费者线程，也就是 push 单线程执行。但生产者从池里取节点仍然是多线程的，因此 pop 依然有 CAS 竞争。靠谱的做法是给空闲指针加上 tag 序号，每次 push/pop 都让 tag 递增，这样就能识别出“同一个节点但版本号不同”的情况。更彻底的做法是每个生产者线程维护一段本地小缓存，减少对共享池的争夺。

6.2 不要拿 x86 的经验赌 ARM64

x86 处理器的内存模型相对较强，普通写操作看起来基本都是有序的，所以很多示例代码在 Intel 上跑一个月也测不出问题。但 ARM64 是弱内存模型，读操作和写操作可能被硬件重排，编译器也可能在优化时打乱顺序。

之前那张关键图必须时刻记着：生产者写 node->Value，然后 Interlocked.Exchange 换 tail，最后 Volatile.Write(ref prev->Next, node)；消费者读取 head->Next 时用 Volatile.Read。这两对 release/acquire 是配对的，缺了任意一个，在 ARM64 上就可能出现消费者看到新节点指针，却读到旧值甚至半初始化的值。

我见过一个反面教材：作者觉得 x86 上没问题，把 Volatile.Write 写成了普通赋值，Intel 服务器压测全绿，一到 ARM 开发板就随机丢数据。无锁队列的跨架构正确性，不能靠“碰运气跑得通”，必须按规范把每一次跨线程传递都做成显式的内存屏障。

6.3 非托管内存的回收与所有权转移

原生队列把 GC 的跟踪成本省掉了，同时把 free 的责任交回给你。队列整个生命周期结束时，队列里可能还残留节点，直接释放所有内存是错的。

正确顺序是先把队列标记为“拒绝新元素”，让生产者停止入队；然后消费者线程把链上剩余节点逐个摘下来归还到池；最后统一释放池里的全部原生内存。如果队列正处于并发使用中，Dispose 不能随便在另一个线程里执行，必须等待所有生产者和消费者退出。

更关键的是节点所有权转移要严格遵循前面说的规则：一个节点只有当它的 Next 不再被生产者写入时，才能被消费者归还到池。我在第一版实现里犯过错误，在 TryDequeue 后立刻把 oldHead 归还池，结果生产者还在往 oldHead 的 Next 上写，导致读到了已经回收到池里的节点。后来改成“只有观察到的 Next 非空才归还”，才稳定下来。

这个东西讲究的就是一个所有权模型：生产者只拥有“自己创建的那个节点”的写权限，消费者只拥有“Next 已经非空”的节点回收权限。只要这个模型不出错，内存就是安全的。

7. 接进生产系统：压测方法、数据与再优化方向

7.1 压测怎么搭才可信

压测这种队列，最忌讳单生产者单消费者。那测出来的数字实际上是内存带宽，而不是无锁竞争能力。可信的配置至少是：

• 3 到 4 个生产者线程，每个线程独立循环向队列写入
• 1 个消费者线程，使用 TryDequeue 或 DrainTo 轮流消费
• 消息量给到 1000 万条以上，避免预热期掩盖真实表现
• 统计维度包括：每秒吞吐、线程分配字节数、GC 触发次数、P99 和 P999 延迟

延迟测量不要在消费者循环里加 Thread.Sleep 模拟业务处理，那会直接把测试变成一个定时任务。如果真要模拟耗时，用精确时间戳记录生产者入队和消费者拿到消息的时间差，另行统计。

我还建议在压测机上先把超线程关掉，或者至少记录 CPU 拓扑。因为这算法依赖缓存行为，超线程下的 SMT 干扰会让数字跳动非常大，影响你判断真正的优化效果。

7.2 一组对比数字与说明

在一台 16 核机器上，用 4 个生产者和 1 个消费者压测 1000 万条 16 字节结构体消息，我得到的典型数字大致如下：

不同机器、不同消息大小，数字都会有很大变化，但量级差异是稳定的。尤其要注意 Allocated 那一列，这才是本质差别。吞吐高一点低一点都可以接受，零分配带来的延迟稳定性才是这种队列存在的意义。

7.3 还能往哪个方向继续优化

如果只是把队列跑通，那已经解决了大部分问题。要进一步压榨性能，有几个方向值得探索。

第一个方向是批量入队。当前入队是每个生产者一次 Exchange，消息特别密集时全局原子操作的次数会很多。可以让生产者先在本地拼一个小的节点链表，然后只做一次 Exchange，把整条子链表挂到队尾。这样全局原子操作的开销被平摊到 N 条消息上，吞吐还能往上走。

第二个方向是给生产者线程增加本地节点缓存。每次 Rent 和 Return 都走共享池，竞争仍存在。让每个 producer 线程先试试本地小栈，本地空了再去共享池取，本地满了再把节点批量还给池。这既降低共享池竞争，也能缓解前面说的 ABA 风险。

第三个方向是深度统计和背压。在入队和出队路径上用原子计数维护 pending 数量，消费端超过阈值时停手刷写，生产端超过阈值时暂缓入队。这能让队列在实际业务里变得可控，而不是无界增长。

第四个方向是缓存行细粒度优化。head 和 tail 已经做了 padding，但如果性能瓶颈还在，可以考虑把空闲池的头指针也独立放到单独缓存行里，并且对整块原生内存做对齐分配。效果需要测量，但思路是通用的：让不同线程共享的变量尽量不挨在一起。

我的体会是，不要一上来就上无锁。先花一天时间用剖析工具确认分配和锁竞争确实是问题，再引入这种原生队列；一旦引入，就要把内存所有权当一等公民来管理。原生队列带来的收益很可观，但它要求你把安全边界想清楚，否则生产环境排起错来，比 GC 停顿麻烦得多。