ConcurrentNativeQueueT：一个使用 .NET 实现的零 GC 压力的无锁 MPSC 原生队列一、为什么要造这个轮子.NET 提供了ConcurrentQueueT和ChannelT两种开箱即用的并发队列。对大多数业务场景，它们已经足够好。但在以下场景中，它们的底层设计决策会成为性能瓶颈：游戏主循环 / 音频管线：GC 停顿（即使是 Gen0）会导致可感知的帧卡顿或音频爆音。即使 Workstation GC 的 Gen0 暂停只有 ~100μs，在 16ms 的帧预算中也可能造成掉帧。高频交易 / 实时数据管线：每微秒都有价值，托管堆分配意味着不可预测的 GC 介入。Native interop 密集场景：数据需要频繁在 managed/unmanaged 边界传递，如果队列本身就在 native 内存上，可以省去 pin/copy 开销。AOT 发布：ConcurrentNativeQueueT是纯unmanaged结构体，天然适合 NativeAOT 场景。ConcurrentNativeQueueT的目标很明确：在 MPSC（多生产者单消费者）模式下，提供零 GC 压力、零托管堆分配的高吞吐量队列。这不是要替代ConcurrentQueueT，而是为那些"对 GC 停顿零容忍"的场景提供一个专用工具。二、整体架构ConcurrentNativeQueueT (struct, unmanaged) ├── _head ──→ [SegmentHeader*] ──→ [SegmentHeader*] ──→ ... │ ↓ ↓ │ [Slot* 数组] [Slot* 数组] │ (已消费,释放) (消费中) │ ├── _tail ──→ [SegmentHeader*] ──→ (预建的下一段) │ ↓ │ [Slot* 数组] │ (生产中) │ ├── _origin ──→ 首段（用于 Dispose 遍历释放所有段头） │ └── 缓存行填充：_head/_dequeuePos 与 _tail 之间 64 字节隔离所有内存（段头结构体 + 槽位数组）均通过NativeMemory分配。ConcurrentNativeQueueT本身也是struct，整个生命周期不产生任何托管堆分配。三、核心技术原理3.1 无锁入队：Volatile.Read + CAS入队操作不使用锁，核心路径只有一次原子操作：// 1. 纯读检测：当前段是否有空位longpos=Volatile.Read(reftail-EnqueuePos.Value);longoffset=pos-tail-BaseIndex;if(offset=tail-Capacity){/* 段满，推进到下一段 */}// 2. CAS 占位if(Interlocked.CompareExchange(reftail-EnqueuePos.Value,pos+1,pos)==pos){// 3. 写入数据，设置标记tail-Slots[offset].Value=item;Volatile.Write(reftail-Slots[offset].State,1);}关键设计点：段满检测是纯读操作（Volatile.Read），不产生任何原子写。多个生产者同时检测到段满时，只有 read 竞争，不会弄脏 cache line。CAS 只在段有空位时才执行。段满时Volatile.Read发现offset = Capacity后直接走段切换路径，避免了无效的原子写。每次入队只有 1 次原子操作（CAS）。3.2 无锁出队：单消费者的极致简化因为约定了单消费者（MPSC 的 SC 部分），出队路径不需要任何原子操作：// 纯本地读：检查 State 标记if(Volatile.Read(refhead-Slots[offset].State)!=1)returnfalse;// 数据还没准备好item=head-Slots[offset].Value;_dequeuePos=pos+1;// 普通写，无需原子操作_dequeuePos是消费者的私有字段，只有单消费者读写，所以普通赋值即可。这比ConcurrentQueueT的 MPMC 出队路径（需要 CAS）快得多。3.3 分段链表 + 指数增长队列不使用单一连续缓冲区，而是由多个段组成的链表。每个段是一个固定大小的原生内存数组：[段 0: 32 slots] → [段 1: 64 slots] → [段 2: 128 slots] → ... → [段 N: 1M slots] 容量指数增长，上限 1M段满时，生产者通过 CAS 创建新段并链接：// 只有一个生产者能成功链接新段if(Interlocked.CompareExchange(refseg-Next,(nint)newSeg,(nint)0)!=(nint)0){// CAS 失败：另一个生产者先创建了，释放多余段NativeMemory.Free(newSeg-Slots);NativeMemory.Free(newSeg);}指数增长的收益：处理 1 亿条数据，段切换只发生约 20 次（32+64+128+…+1M+1M+…）。而固定 32 大小需要 300 多万次段切换。3.4 预建下一段当段接近满时（剩余 ≤ 16 个槽位），生产者在写入成功后提前分配下一段：if(offset+1=tail-Capacity-PreBuildSlotsVolatile.Read(reftail-Next)==(nint)0)EnsureNextSegment(tail);这样当段真正满时，新段已经准备好了，TryAdvanceTail只需一次 CAS 推进尾指针。代价是每次 Enqueue 多一个必定被预测为 false的分支（~0 额外开销）。3.5 两阶段内存回收这是全 native 化设计中最核心的生命周期问题。为什么段头不能在消费后立即释放？因为生产者可能在任意时刻被 OS 抢占，此时它持有旧段的裸指针。如果消费者释放了这个段头，生产者恢复后会访问已释放的内存（use-after-free）。解决方案：阶段释放内容时机安全性依据阶段 1槽位数组（Slot*）消费者消费完整段后立即释放所有State == 1→ 所有生产者已写完并离开该槽位阶段 2段头结构体（SegmentHeader*）Dispose()时从_origin遍历释放队列不再使用，无并发访问段头只有 ~160 字节，指数增长使段头数量为对数级别：处理 10 亿条数据 ≈ 1000 个段头 ≈ 200KB，完全可忽略。3.6 False Sharing 防护在多核 CPU 上，如果生产者和消费者的热点字段位于同一条 64 字节缓存行上，每次写入都会导致对方核心的缓存行失效（false sharing），严重降低性能。// ── 消费者缓存行 ──privateSegmentHeader*_head;