有一阵子我调一个实时特征服务单路数据流的延迟总是莫名抖动。业务线程往一个std::queue里 push 数据消费线程再 pop 出来处理原本队列基本是空的延迟也很漂亮但一旦上游抖动队列积压到几百条尾延迟马上从几十微秒飙到几十毫秒。后来我把这段换成了一个高性能线程安全环形缓冲区——CRingBuffer整个问题立刻消停了尾延迟重新回到微秒级。也就是从那次开始我意识到环形缓冲区这类结构在并发链路里的价值不是靠运气而是它从根上规避了队列方案的三个隐藏代价。这篇文章就把我设计和落地 CRingBuffer 的过程完整拆开从为什么选环形、数据结构怎么定、线程安全靠什么保证到缓存行怎么对齐、批量接口怎么设计、实测数据长什么样一次性讲透。适合正在做高吞吐数据链路的 C/C 开发者也适合对无锁并发有兴趣、想搞明白“无锁到底怎么保证安全”的读者。1. 为什么是环形而不是队列一次性能瓶颈的真实复盘1.1 事故现场尾延迟从微秒级漂到毫秒级先还原一下当时的场景。线上有一个实时特征计算服务上游推送的特征包大小不固定几十字节到几百字节都有。服务内部分两个线程接收线程负责把包从网络回调里拿过来处理线程负责解包、跑特征计算。两个线程之间最初就是std::queuePacket std::mutex std::condition_variable。正常流量下这套组合没问题队列永远只有零到几个包push和pop基本不冲突延迟也很稳定。但流量高峰一来积压一多问题全出来了每次push都可能触发堆内存分配队列积压越深malloc 调用越频繁线程在锁上发生睡眠唤醒一次 syscall 来回可能上百微秒链式结构里每个节点散落在堆的不同地址CPU 缓存根本没法高效预取。最终表现就是平均延迟还凑合但 P99、P99.9 尾延迟烂得没法看。而这种抖动在实时链路上比平均延迟高更要命。1.2 有锁队列的三个隐藏代价很多人觉得锁队列慢是“锁本身慢”其实只对了一部分。真正的问题往往藏在三个更隐蔽的地方第一个代价是动态内存分配。std::queue底层默认是std::deque元素增长到一定量级会分配新内存块。malloc 本身就可能触发系统调用分配器为了线程安全还要竞争全局锁或者 arena在高并发进程里malloc 的代价常常比业务逻辑还高。环形缓冲区的内存是初始化时一次性分配好、之后反复复用的天然没有分配器压力。第二个代价是锁竞争导致的线程状态切换。当队列从空变成有数据消费者被条件变量唤醒这个过程涉及用户态到内核态的切换。如果数据每来一批就唤醒一次消费线程的高频切换开销是极难压下去的。第三个代价是缓存不友好。链表或者 deque 的节点在内存里不是连续排布的CPU 从内存读一个节点可能要把前后好几个 cache line 都拉进来但里面根本没有你要的数据。缓冲区是连续大块内存读写基本都落在最近访问过的 cache line 上效率高一个量级。1.3 环形缓冲区为什么能翻身环形缓冲区本质上是一块固定大小的连续内存配两个只增不减的下标写下标和读下标。生产者往“写下标指向的位置”写入数据然后把写下标加一消费者从“读下标指向的位置”取数据然后把读下标加一。下标超过容量后通过按位与或者取模回到开头形成一个环。这个设计的关键好处有四个无内存分配存储空间预先分配好运行期没有任何堆操作无锁机会单生产者单消费者场景下两个线程各写各的下标没有共享可变状态完全可以不加锁缓存友好数据在连续内存里顺序写入、顺序读取硬件预取器非常喜欢这种访问模式可预测延迟没有动态分配、没有系统调用操作路径是固定的几条赋值和原子指令延迟分布非常集中。1.4 选型对照什么时候别迷信环形缓冲区环形缓冲区不是万能的我自己用下来选型逻辑是这样的方案内存分配一致性保障延迟抖动适用场景std::queue mutex动态分配频繁 malloc锁保护强一致高P99 差低吞吐、开发效率优先带锁环形缓冲区预分配无运行期分配锁保护强一致较低可接受多读多写、正确性优先SPSC 无锁环形缓冲区预分配无运行期分配内存序保证最终一致极低稳定单生产者单消费者、高吞吐MPMC 无锁队列通常预分配算法复杂易踩坑视实现而定极少数多写多读高吞吐场景重要如果你只有一对线程交互数据SPSC 环形缓冲区是性价比最高的几乎无脑选。如果能用多个独立队列把数据分片也别急着上 MPMC。多头多尾的无锁队列复杂度是几何级上升的99% 的业务场景用“分片 SPSC”或者“短临界区锁环形缓冲区”就够了。2. CRingBuffer 核心结构容量、掩码与读写路径2.1 容量为什么必须是 2 的幂设计 CRingBuffer 第一件事就是定容量。我的建议永远是取 2 的幂比如 1024、4096、65536。原因很简单环形下标回绕时取模运算index % capacity会被编译器优化成一次除法而除法在 CPU 上比位运算慢得多。如果容量是 2 的幂回绕可以直接写成index mask其中mask capacity - 1。不要小看这一个除法。在百万级 QPS 的路径上每个元素省掉几十个 CPU 周期累计收益非常可观。而且 2 的幂容量还有个隐性好处当你把读写下标的差值判断用无符号整数处理时只要容量不超过无符号整数范围的一半回绕后的差值依然正确。2.2 核心结构体与初始化细节我用的核心结构大致长这样#include stdatomic.h #include stddef.h #include string.h #define CRB_CACHELINE_SIZE 64 typedef struct { size_t capacity; /* 元素个数必须是2的幂 */ size_t mask; /* capacity - 1 */ size_t elem_size; /* 单个元素字节数 */ } crb_control_t; typedef struct { _Atomic size_t read_idx; /* 读下标消费者维护 */ char pad0[CRB_CACHELINE_SIZE - sizeof(size_t)]; _Atomic size_t write_idx; /* 写下标生产者维护 */ char pad1[CRB_CACHELINE_SIZE - sizeof(size_t)]; } crb_indexes_t; typedef struct { crb_control_t control; crb_indexes_t indexes; unsigned char data[]; /* 柔性数组存放实际元素 */ } cr_buffer_t;这里两个 atomic 变量中间人为填了 padding让read_idx和write_idx落在不同的 cache line 上。这个细节在后面讲伪共享时会展开现在先记住结论读写下标必须隔离。初始化时需要把mask设成capacity - 1并把两个下标清零。这里有个容易翻车的点柔性数组data[]的起始地址需要按elem_size对齐尤其当元素是结构体、内含int64或指针时错位对齐会导致未定义行为。我习惯在分配时手动对齐#include stdlib.h cr_buffer_t *crb_create(size_t capacity, size_t elem_size) { if ((capacity (capacity - 1)) ! 0) { return NULL; /* 容量必须是2的幂 */ } size_t total sizeof(cr_buffer_t) capacity * elem_size CRB_CACHELINE_SIZE - 1; cr_buffer_t *b aligned_alloc(CRB_CACHELINE_SIZE, total); if (!b) { return NULL; } memset(b, 0, total); b-control.capacity capacity; b-control.mask capacity - 1; b-control.elem_size elem_size; return b; }2.3 单生产者单消费者的无锁读写路径这里给出我实际在用的 SPSC 版本读写函数。整个实现不包含任何锁和 CAS靠的是 C11 原子变量的内存序。int crb_push(cr_buffer_t *b, const void *elem) { size_t w atomic_load_explicit(b-indexes.write_idx, memory_order_relaxed); size_t r atomic_load_explicit(b-indexes.read_idx, memory_order_acquire); if (w - r b-control.capacity) { return -1; /* 缓冲已满 */ } size_t pos (w b-control.mask) * b-control.elem_size; memcpy(b-data[pos], elem, b-control.elem_size); atomic_store_explicit(b-indexes.write_idx, w 1, memory_order_release); return 0; } int crb_pop(cr_buffer_t *b, void *elem) { size_t r atomic_load_explicit(b-indexes.read_idx, memory_order_relaxed); size_t w atomic_load_explicit(b-indexes.write_idx, memory_order_acquire); if (r w) { return -1; /* 缓冲为空 */ } size_t pos (r b-control.mask) * b-control.elem_size; memcpy(elem, b-data[pos], b-control.elem_size); atomic_store_explicit(b-indexes.read_idx, r 1, memory_order_release); return 0; }这段代码有两个关键点值得说。第一写数据时把元素拷贝到buffer[pos]这一步是普通内存写不需要原子操作真正让数据“对外可见”的是随后那次write_idx的 release 存储。读数据时消费者先 acquire 加载write_idx然后才能从对应位置拷贝数据。release-acquire 这对组合保证了“写数据”一定发生在“更新写下标”之前“读到写下标更新”一定发生在“读取数据”之后。第二push里读read_idx为什么要用 acquire因为消费者在下一次pop之后会用 release 更新read_idx生产者必须 acquire 读取它才能确保确实“看到”了消费者释放出来的存储空间。同理pop里加载write_idx也要用 acquire。2.4 满与空的判定以及下标差值为什么不会失控很多环形缓冲区实现会牺牲一个槽位来区分“满”和“空”即write_idx 1 read_idx当作满。CRingBuffer 不需要因为这里用w - r capacity判断满用r w判断空两者不可能混淆。为什么w - r不会因为回绕而算错因为w和r都是无符号整数回绕本质上就是模运算。只要缓冲区里最多容纳的元素数量capacity小于无符号整数能表示范围的一半那么任意时刻的未读元素数量w - r都会在正确范围内。比如size_t是 64 位w回绕一次后数值变得很小但和r的差值依然等于实际未读数量。要注意这里的capacity、w - r都是元素个数不是字节。我见过有人把乘了elem_size之后的字节数拿去比较结果容量判断完全错乱。下标永远用“个数”衡量数据偏移才用“个数乘单个元素大小”。3. 线程安全核心内存序、CAS 与多生产消费模型3.1 没有锁靠什么保证安全内存序入门很多人一听“无锁”就以为是不用同步其实大错特错。无锁只是不用操作系统提供的互斥锁线程之间的协作依赖的是原子操作和内存序。你得先明白四件小事原子操作保证的是“读改写”的不可分割性但单次读写本身也可以只约束顺序。memory_order_relaxed只保证原子性不保证顺序适合不需要同步语义的计数器。memory_order_release保证当前线程在此之前的普通内存写不会重排到发布操作之后。memory_order_acquire保证当前线程在此之后的普通内存读不会重排到获取操作之前。release 和 acquire 必须成对出现才有意义。生产者 release 了一个值消费者 acquire 同一个值后生产者 release 之前的所有写入对消费者都是可见的。这就是拿write_idx当“发布信号”的底层原理。3.2 在 x86 上release/acquire 几乎是免费的写无锁代码时选内存序不只是“正确性”问题更是性能问题。最简单粗暴的方案是全用memory_order_seq_cst保证全局一致顺序。但顺序一致在弱内存序的 ARM 处理器上往往要插入完整内存屏障开销非常大在 x86 上虽然不额外插入屏障但编译器优化被限制得更严整体性能仍有损耗。CRingBuffer 的 SPSC 路径只用了relaxed、acquire和release。x86 的硬件模型本身是 TSOTotal Store Order普通 store 天然带 release 语义普通 load 天然带 acquire 语义所以acquire/release在这类平台上基本不会生成多余的屏障指令只约束编译期的指令重排。这也是 SPSC 无锁环形缓冲区在 x86 上那么快的原因之一。注意在 ARM、RISC-V 这类弱内存序平台上release/acquire会生成必要的屏障指令但依然比seq_cst便宜。跨平台实现无锁队列时内存序的选择决定最终性能差是 1.2 倍还是 3 倍。3.3 多生产者多消费者直接抢下标会碰到什么如果现在有两个生产者线程同时执行crb_push里的w load(write_idx)然后各自拿到相同的w写同一个位置数据互相覆盖。解决思路是把“拿位置”这一步改成原子递增size_t pos atomic_fetch_add(b-indexes.write_idx, 1, memory_order_relaxed);但这只是第一层坑。拿到位置之后数据还没来得及写进buffer[pos]另一个消费者可能已经读到了“新写下标”跑过来把半成品数据当成品拿走。更麻烦的两个生产者之间线程 A 拿到位置 0线程 B 拿到位置 1B 先写完A 后写完消费者按顺序读时会先读到位置 0 的空洞数据。所以真正的 MPMC 无锁环形缓冲区还需要给每个槽位加“状态字段”用EMPTY / WRITING / READY标识或者用复杂的双阶段提交、DCASDouble Compare-and-Swap方案。这块的代码复杂度、正确性验证成本比 SPSC 高出非常多。3.4 我的建议先分片再考虑 MPMC实战中我几乎不建议一上来就写 MPMC 无锁环形缓冲区。原因很朴素分片方案简单得多性能也在线。假如有 4 个生产者线程往下游传数据可以给每个生产者单独分配一个 SPSC 环形缓冲区消费者轮询这 4 个缓冲区。每路都是单一写者天然满足 SPSC 的前提条件。即使消费者需要合并多个队列轮询的开销也远小于维护超级复杂的无锁 MPMC。如果分片做不到退而求其次用“短临界区锁 环形缓冲区”int crb_push_locked(cr_buffer_t *b, const void *elem) { int ret; spinlock_lock(b-lock); ret crb_push(b, elem); spinlock_unlock(b-lock); return ret; }自旋锁临界区里只做“检查位置 拷贝元素 更新下标”整个临界区只有几十纳秒量级。竞争不激烈时它和完全无锁实现的吞吐差距非常小但正确性要容易验证得多。等压测数据证明锁是瓶颈了再考虑上复杂度更高的方案。4. 缓存行与批量操作两个最容易被忽略的性能命门4.1 伪共享两个原子变量挨着放会翻车一个容易让 SPSC 性能雪崩的问题是读写下标被放进了同一条 cache line。CPU 缓存以 64 字节的 cache line 为粒度管理数据。如果read_idx和write_idx在同一个 cache line 里生产者更新write_idx时会让包含它的整条 cache line 失效消费者的 CPU 内核本来缓存了同一条 line发现自己这份过期了必须重新从内存拉取。反过来消费者更新read_idx也一样。这就形成了两个核之间高频的 cache line 乒乓虽然程序逻辑上没有任何共享写数据却实际在缓存层级间来回倒腾性能可能下降一个量级。这就是伪共享。CRingBuffer 在结构体里给两个下标各自加了 padding让它们占用不同的 cache line是解决伪共享的第一步。第二步缓冲的数据区最好也和下标区域分隔开避免每次读写数据都让“下标所在 cache line”跟着刷新。4.2 对齐到缓存行后的实测印象我没法给你一套普适的精确收益数据但有印象的参考值是伪共享未消除时SPSC 单次 push-pop 往返延迟受干扰明显抖动加剧消除后延迟分布集中许多、吞吐明显上升。尤其是多核跨 NUMA 的机器上效果更夸张。验证伪共享的方法也不难用perf c2c看缓存冲突或者在两个下标之间加/不加 padding 分别跑压测对比 P99。我在调 CRingBuffer 时就是用这个方法确认为什么“明明无锁却慢得离谱”。4.3 批量接口设计从单个搬运升级为连续切片单元素push / pop接口简单但每次调用有一对 atomic 操作的固定开销。如果生产者一次性生产多条数据消费者也希望一次取一批那么批量接口的价值就很大。批量接口的设计要点是把“连续区域”暴露出来而不是逐个拷贝。环形缓冲区有一个特点可读区域可能跨过环形边界分成前后两段。我把接口设计成“申请读块”的形式typedef struct { void *seg1; size_t len1; void *seg2; size_t len2; } crb_slice_t; /* 一次申请最多 max_count 个元素返回两个连续段 */ size_t crb_read_acquire(cr_buffer_t *b, size_t max_count, crb_slice_t *slice); /* 读完提交真正推进 read_idx */ void crb_read_release(cr_buffer_t *b, size_t count);生产者侧也有对应的crb_write_reserve / crb_write_commit。拿到两段指针之后可以直接交给writev/readv做零拷贝转发或者自己按段批量 memcpy。这样固定开销从“每元素一次原子操作”降成“每批一次或两次原子操作”高吞吐路径上的效果立竿见影。4.4 预取与编译器层面的微调批量接口之外还有两个顺手可做的优化。一是利用 CPU 预取指令。消费端总是顺序读可以在读完第 N 个元素之前用__builtin_prefetch(data[(r 8) mask])去预取后面若干 cache line生产端同理。数据密集流转时预取能让内存等待时间大幅隐藏。二是保证循环里没有不可控的函数调用。比如memcpy对于小元素会被编译器内联但elem_size必须是对编译器可见的常量或结构体字段否则可能调用库函数引入额外开销。如果固定元素大小建议直接把它做成编译期常量比如往缓冲区的拷贝用memcpy(dst, src, sizeof(my_type))。5. 应用落地与实测参数从音频流到异步日志5.1 异步日志缓冲业务线程不再卡 IO日志是最典型的环形缓冲区应用。业务线程写日志如果直接写文件磁盘抖动时会把整个业务卡住。引入 CRingBuffer 后业务线程只负责把日志行拷贝进缓冲区后台专用线程批量取走并刷盘。在这个场景里我一般选“满则丢弃”策略而不是“满则阻塞”。日志本来就是采样性数据尾部少量丢失远比业务线程卡死可接受。缓冲区容量按“峰值日志速率 × 峰值持续时间”估算比如每秒钟最多产生 200MB 日志、需要撑 2 秒单条日志平均 200 字节那容量至少 200MB。用环形缓冲区时容量按字节数除以单条最大长度去换算成元素个数同时留出 2 到 3 倍余量。5.2 音频全双工链路流式数据天然适合环音频采集线程和播放线程之间传递的是固定大小的 PCM 帧。采集线程按采样率周期性写入播放线程按声卡时钟周期性读取两者时钟并不完全同步环形缓冲恰好作为吸收抖动的中间水库。容量配置有个经验值按流媒体场景缓冲区至少要能容纳 20 到 50 毫秒的音频数据。48kHz 采样率、每帧 4 字节20 毫秒大约是 960 个采样帧。设成 1024 或 2048 都合适。设太大反而会让延迟增加设太小则容易出现 underrun 或 overflow。5.3 网络收发缓冲用 IO 向量绕过两次拷贝网络收包线程把报文压入环形缓冲协议处理线程批量取走。如果缓冲区里的报文是连续存放的处理线程拿到切片后可以直接组struct iovec传给writev发送避免把分散数据先拼进一个大缓冲再发送。读侧同理readv读到两段切片后直接提交给上层协议栈省掉一次中间拷贝。吞吐越高省下来的拷贝越可观。5.4 容量与元素大小怎么定一个可套用的估算方法很多人问环形缓冲区容量到底设多大。我的估算公式很简单容量 峰值生产速率 × 允许的最大阻塞时间 / 单个元素大小然后向上取整到最近的 2 的幂再乘 2 到 3 倍的余量系数。比如生产者峰值每秒 100 万个元素允许消费者最大只延迟 5 毫秒那么缓冲区至少能撑 5000 个元素。取 8192 比较稳。元素大小影响的是总内存8192 × 256 字节 ≈ 2MB完全可接受。如果元素非常大几 KB 以上建议缓冲区只存“指针”或“偏移量”数据本体放独立的内存池。否则环形缓冲区本身的内存占用会失控拷贝大对象的开销也会成为瓶颈。CRingBuffer 的元素类型应当保持小而固定变更元素大小时重新初始化不要在运行期动态调整。5.5 压测方法与参考数据压测 SPSC 环形缓冲区建议绑核跑把生产者和消费者分别固定在两个不同的 CPU 核心上避免线程迁移干扰。我用的是clock_gettime(CLOCK_MONOTONIC)测批量 push-pop 的往返连续跑几百万次统计 P50、P99、最大延迟。一个合理的参考量级单生产者单消费者、元素 64 字节、批量 32 个元素的情况下x86 平台上的往返吞吐通常能达到每秒上千万到几千万个元素单次延迟集中在几十到几百纳秒量级。具体数值取决于 CPU、内存布局和编译优化别拿我的数字当你们机器的验收标准但相对趋势是一致的SPSC 无锁环形缓冲区的延迟分布非常紧凑基本没有离群点。5.6 开发期必须做的检查ThreadSanitizer 与统计监控无锁代码最怕改着改着引入数据竞争。我每次动 CRingBuffer 的代码都会用-fsanitizethread跑一轮压力测试。注意 ThreadSanitizer 对无锁代码的内存序只能说不撒谎但它确实能抓到大多数“真正的数据竞争”一个变量被并发读写且至少一方在写却没有被原子操作保护。另一个习惯是在缓冲区里加统计字段记录出现过多少次满、多少次空、生产者和消费者各自推进的总数。线上跑一段时间后这些数字能直接告诉你容量是否合理、生产消费速率是否匹配。有一次线上日志丢失我就是靠“满计数”字段定位到了消费线程被磁盘 IO 卡死的问题。提示无锁代码调试难维护更难。结构体改动后先跑 ThreadSanitizer再用perf看缓存争用最后再上高并发压测。顺序反了出了问题往往定位得怀疑人生。最后再分享一个我自己的习惯每次写环形缓冲区我都会先问自己这里真的需要 MPMC 吗答案绝大多数时候是不需要。分片 SPSC、或者带锁的短临界区环形缓冲区已经覆盖了 95% 以上的现实场景。CRingBuffer 最核心的价值是它用一块固定内存换掉了动态分配、用一对原子下标换掉了锁、用连续内存换掉了指针追逐。真正让它跑得飞快的不是某个玄妙的算法而是这几个朴素原则叠加在一起的效果。把每条数据路径上的固定开销降到最低延迟自然就稳了。
有一阵子我调一个实时特征服务单路数据流的延迟总是莫名抖动。业务线程往一个std::queue里 push 数据消费线程再 pop 出来处理原本队列基本是空的延迟也很漂亮但一旦上游抖动队列积压到几百条尾延迟马上从几十微秒飙到几十毫秒。后来我把这段换成了一个高性能线程安全环形缓冲区——CRingBuffer整个问题立刻消停了尾延迟重新回到微秒级。也就是从那次开始我意识到环形缓冲区这类结构在并发链路里的价值不是靠运气而是它从根上规避了队列方案的三个隐藏代价。这篇文章就把我设计和落地 CRingBuffer 的过程完整拆开从为什么选环形、数据结构怎么定、线程安全靠什么保证到缓存行怎么对齐、批量接口怎么设计、实测数据长什么样一次性讲透。适合正在做高吞吐数据链路的 C/C 开发者也适合对无锁并发有兴趣、想搞明白“无锁到底怎么保证安全”的读者。1. 为什么是环形而不是队列一次性能瓶颈的真实复盘1.1 事故现场尾延迟从微秒级漂到毫秒级先还原一下当时的场景。线上有一个实时特征计算服务上游推送的特征包大小不固定几十字节到几百字节都有。服务内部分两个线程接收线程负责把包从网络回调里拿过来处理线程负责解包、跑特征计算。两个线程之间最初就是std::queuePacket std::mutex std::condition_variable。正常流量下这套组合没问题队列永远只有零到几个包push和pop基本不冲突延迟也很稳定。但流量高峰一来积压一多问题全出来了每次push都可能触发堆内存分配队列积压越深malloc 调用越频繁线程在锁上发生睡眠唤醒一次 syscall 来回可能上百微秒链式结构里每个节点散落在堆的不同地址CPU 缓存根本没法高效预取。最终表现就是平均延迟还凑合但 P99、P99.9 尾延迟烂得没法看。而这种抖动在实时链路上比平均延迟高更要命。1.2 有锁队列的三个隐藏代价很多人觉得锁队列慢是“锁本身慢”其实只对了一部分。真正的问题往往藏在三个更隐蔽的地方第一个代价是动态内存分配。std::queue底层默认是std::deque元素增长到一定量级会分配新内存块。malloc 本身就可能触发系统调用分配器为了线程安全还要竞争全局锁或者 arena在高并发进程里malloc 的代价常常比业务逻辑还高。环形缓冲区的内存是初始化时一次性分配好、之后反复复用的天然没有分配器压力。第二个代价是锁竞争导致的线程状态切换。当队列从空变成有数据消费者被条件变量唤醒这个过程涉及用户态到内核态的切换。如果数据每来一批就唤醒一次消费线程的高频切换开销是极难压下去的。第三个代价是缓存不友好。链表或者 deque 的节点在内存里不是连续排布的CPU 从内存读一个节点可能要把前后好几个 cache line 都拉进来但里面根本没有你要的数据。缓冲区是连续大块内存读写基本都落在最近访问过的 cache line 上效率高一个量级。1.3 环形缓冲区为什么能翻身环形缓冲区本质上是一块固定大小的连续内存配两个只增不减的下标写下标和读下标。生产者往“写下标指向的位置”写入数据然后把写下标加一消费者从“读下标指向的位置”取数据然后把读下标加一。下标超过容量后通过按位与或者取模回到开头形成一个环。这个设计的关键好处有四个无内存分配存储空间预先分配好运行期没有任何堆操作无锁机会单生产者单消费者场景下两个线程各写各的下标没有共享可变状态完全可以不加锁缓存友好数据在连续内存里顺序写入、顺序读取硬件预取器非常喜欢这种访问模式可预测延迟没有动态分配、没有系统调用操作路径是固定的几条赋值和原子指令延迟分布非常集中。1.4 选型对照什么时候别迷信环形缓冲区环形缓冲区不是万能的我自己用下来选型逻辑是这样的方案内存分配一致性保障延迟抖动适用场景std::queue mutex动态分配频繁 malloc锁保护强一致高P99 差低吞吐、开发效率优先带锁环形缓冲区预分配无运行期分配锁保护强一致较低可接受多读多写、正确性优先SPSC 无锁环形缓冲区预分配无运行期分配内存序保证最终一致极低稳定单生产者单消费者、高吞吐MPMC 无锁队列通常预分配算法复杂易踩坑视实现而定极少数多写多读高吞吐场景重要如果你只有一对线程交互数据SPSC 环形缓冲区是性价比最高的几乎无脑选。如果能用多个独立队列把数据分片也别急着上 MPMC。多头多尾的无锁队列复杂度是几何级上升的99% 的业务场景用“分片 SPSC”或者“短临界区锁环形缓冲区”就够了。2. CRingBuffer 核心结构容量、掩码与读写路径2.1 容量为什么必须是 2 的幂设计 CRingBuffer 第一件事就是定容量。我的建议永远是取 2 的幂比如 1024、4096、65536。原因很简单环形下标回绕时取模运算index % capacity会被编译器优化成一次除法而除法在 CPU 上比位运算慢得多。如果容量是 2 的幂回绕可以直接写成index mask其中mask capacity - 1。不要小看这一个除法。在百万级 QPS 的路径上每个元素省掉几十个 CPU 周期累计收益非常可观。而且 2 的幂容量还有个隐性好处当你把读写下标的差值判断用无符号整数处理时只要容量不超过无符号整数范围的一半回绕后的差值依然正确。2.2 核心结构体与初始化细节我用的核心结构大致长这样#include stdatomic.h #include stddef.h #include string.h #define CRB_CACHELINE_SIZE 64 typedef struct { size_t capacity; /* 元素个数必须是2的幂 */ size_t mask; /* capacity - 1 */ size_t elem_size; /* 单个元素字节数 */ } crb_control_t; typedef struct { _Atomic size_t read_idx; /* 读下标消费者维护 */ char pad0[CRB_CACHELINE_SIZE - sizeof(size_t)]; _Atomic size_t write_idx; /* 写下标生产者维护 */ char pad1[CRB_CACHELINE_SIZE - sizeof(size_t)]; } crb_indexes_t; typedef struct { crb_control_t control; crb_indexes_t indexes; unsigned char data[]; /* 柔性数组存放实际元素 */ } cr_buffer_t;这里两个 atomic 变量中间人为填了 padding让read_idx和write_idx落在不同的 cache line 上。这个细节在后面讲伪共享时会展开现在先记住结论读写下标必须隔离。初始化时需要把mask设成capacity - 1并把两个下标清零。这里有个容易翻车的点柔性数组data[]的起始地址需要按elem_size对齐尤其当元素是结构体、内含int64或指针时错位对齐会导致未定义行为。我习惯在分配时手动对齐#include stdlib.h cr_buffer_t *crb_create(size_t capacity, size_t elem_size) { if ((capacity (capacity - 1)) ! 0) { return NULL; /* 容量必须是2的幂 */ } size_t total sizeof(cr_buffer_t) capacity * elem_size CRB_CACHELINE_SIZE - 1; cr_buffer_t *b aligned_alloc(CRB_CACHELINE_SIZE, total); if (!b) { return NULL; } memset(b, 0, total); b-control.capacity capacity; b-control.mask capacity - 1; b-control.elem_size elem_size; return b; }2.3 单生产者单消费者的无锁读写路径这里给出我实际在用的 SPSC 版本读写函数。整个实现不包含任何锁和 CAS靠的是 C11 原子变量的内存序。int crb_push(cr_buffer_t *b, const void *elem) { size_t w atomic_load_explicit(b-indexes.write_idx, memory_order_relaxed); size_t r atomic_load_explicit(b-indexes.read_idx, memory_order_acquire); if (w - r b-control.capacity) { return -1; /* 缓冲已满 */ } size_t pos (w b-control.mask) * b-control.elem_size; memcpy(b-data[pos], elem, b-control.elem_size); atomic_store_explicit(b-indexes.write_idx, w 1, memory_order_release); return 0; } int crb_pop(cr_buffer_t *b, void *elem) { size_t r atomic_load_explicit(b-indexes.read_idx, memory_order_relaxed); size_t w atomic_load_explicit(b-indexes.write_idx, memory_order_acquire); if (r w) { return -1; /* 缓冲为空 */ } size_t pos (r b-control.mask) * b-control.elem_size; memcpy(elem, b-data[pos], b-control.elem_size); atomic_store_explicit(b-indexes.read_idx, r 1, memory_order_release); return 0; }这段代码有两个关键点值得说。第一写数据时把元素拷贝到buffer[pos]这一步是普通内存写不需要原子操作真正让数据“对外可见”的是随后那次write_idx的 release 存储。读数据时消费者先 acquire 加载write_idx然后才能从对应位置拷贝数据。release-acquire 这对组合保证了“写数据”一定发生在“更新写下标”之前“读到写下标更新”一定发生在“读取数据”之后。第二push里读read_idx为什么要用 acquire因为消费者在下一次pop之后会用 release 更新read_idx生产者必须 acquire 读取它才能确保确实“看到”了消费者释放出来的存储空间。同理pop里加载write_idx也要用 acquire。2.4 满与空的判定以及下标差值为什么不会失控很多环形缓冲区实现会牺牲一个槽位来区分“满”和“空”即write_idx 1 read_idx当作满。CRingBuffer 不需要因为这里用w - r capacity判断满用r w判断空两者不可能混淆。为什么w - r不会因为回绕而算错因为w和r都是无符号整数回绕本质上就是模运算。只要缓冲区里最多容纳的元素数量capacity小于无符号整数能表示范围的一半那么任意时刻的未读元素数量w - r都会在正确范围内。比如size_t是 64 位w回绕一次后数值变得很小但和r的差值依然等于实际未读数量。要注意这里的capacity、w - r都是元素个数不是字节。我见过有人把乘了elem_size之后的字节数拿去比较结果容量判断完全错乱。下标永远用“个数”衡量数据偏移才用“个数乘单个元素大小”。3. 线程安全核心内存序、CAS 与多生产消费模型3.1 没有锁靠什么保证安全内存序入门很多人一听“无锁”就以为是不用同步其实大错特错。无锁只是不用操作系统提供的互斥锁线程之间的协作依赖的是原子操作和内存序。你得先明白四件小事原子操作保证的是“读改写”的不可分割性但单次读写本身也可以只约束顺序。memory_order_relaxed只保证原子性不保证顺序适合不需要同步语义的计数器。memory_order_release保证当前线程在此之前的普通内存写不会重排到发布操作之后。memory_order_acquire保证当前线程在此之后的普通内存读不会重排到获取操作之前。release 和 acquire 必须成对出现才有意义。生产者 release 了一个值消费者 acquire 同一个值后生产者 release 之前的所有写入对消费者都是可见的。这就是拿write_idx当“发布信号”的底层原理。3.2 在 x86 上release/acquire 几乎是免费的写无锁代码时选内存序不只是“正确性”问题更是性能问题。最简单粗暴的方案是全用memory_order_seq_cst保证全局一致顺序。但顺序一致在弱内存序的 ARM 处理器上往往要插入完整内存屏障开销非常大在 x86 上虽然不额外插入屏障但编译器优化被限制得更严整体性能仍有损耗。CRingBuffer 的 SPSC 路径只用了relaxed、acquire和release。x86 的硬件模型本身是 TSOTotal Store Order普通 store 天然带 release 语义普通 load 天然带 acquire 语义所以acquire/release在这类平台上基本不会生成多余的屏障指令只约束编译期的指令重排。这也是 SPSC 无锁环形缓冲区在 x86 上那么快的原因之一。注意在 ARM、RISC-V 这类弱内存序平台上release/acquire会生成必要的屏障指令但依然比seq_cst便宜。跨平台实现无锁队列时内存序的选择决定最终性能差是 1.2 倍还是 3 倍。3.3 多生产者多消费者直接抢下标会碰到什么如果现在有两个生产者线程同时执行crb_push里的w load(write_idx)然后各自拿到相同的w写同一个位置数据互相覆盖。解决思路是把“拿位置”这一步改成原子递增size_t pos atomic_fetch_add(b-indexes.write_idx, 1, memory_order_relaxed);但这只是第一层坑。拿到位置之后数据还没来得及写进buffer[pos]另一个消费者可能已经读到了“新写下标”跑过来把半成品数据当成品拿走。更麻烦的两个生产者之间线程 A 拿到位置 0线程 B 拿到位置 1B 先写完A 后写完消费者按顺序读时会先读到位置 0 的空洞数据。所以真正的 MPMC 无锁环形缓冲区还需要给每个槽位加“状态字段”用EMPTY / WRITING / READY标识或者用复杂的双阶段提交、DCASDouble Compare-and-Swap方案。这块的代码复杂度、正确性验证成本比 SPSC 高出非常多。3.4 我的建议先分片再考虑 MPMC实战中我几乎不建议一上来就写 MPMC 无锁环形缓冲区。原因很朴素分片方案简单得多性能也在线。假如有 4 个生产者线程往下游传数据可以给每个生产者单独分配一个 SPSC 环形缓冲区消费者轮询这 4 个缓冲区。每路都是单一写者天然满足 SPSC 的前提条件。即使消费者需要合并多个队列轮询的开销也远小于维护超级复杂的无锁 MPMC。如果分片做不到退而求其次用“短临界区锁 环形缓冲区”int crb_push_locked(cr_buffer_t *b, const void *elem) { int ret; spinlock_lock(b-lock); ret crb_push(b, elem); spinlock_unlock(b-lock); return ret; }自旋锁临界区里只做“检查位置 拷贝元素 更新下标”整个临界区只有几十纳秒量级。竞争不激烈时它和完全无锁实现的吞吐差距非常小但正确性要容易验证得多。等压测数据证明锁是瓶颈了再考虑上复杂度更高的方案。4. 缓存行与批量操作两个最容易被忽略的性能命门4.1 伪共享两个原子变量挨着放会翻车一个容易让 SPSC 性能雪崩的问题是读写下标被放进了同一条 cache line。CPU 缓存以 64 字节的 cache line 为粒度管理数据。如果read_idx和write_idx在同一个 cache line 里生产者更新write_idx时会让包含它的整条 cache line 失效消费者的 CPU 内核本来缓存了同一条 line发现自己这份过期了必须重新从内存拉取。反过来消费者更新read_idx也一样。这就形成了两个核之间高频的 cache line 乒乓虽然程序逻辑上没有任何共享写数据却实际在缓存层级间来回倒腾性能可能下降一个量级。这就是伪共享。CRingBuffer 在结构体里给两个下标各自加了 padding让它们占用不同的 cache line是解决伪共享的第一步。第二步缓冲的数据区最好也和下标区域分隔开避免每次读写数据都让“下标所在 cache line”跟着刷新。4.2 对齐到缓存行后的实测印象我没法给你一套普适的精确收益数据但有印象的参考值是伪共享未消除时SPSC 单次 push-pop 往返延迟受干扰明显抖动加剧消除后延迟分布集中许多、吞吐明显上升。尤其是多核跨 NUMA 的机器上效果更夸张。验证伪共享的方法也不难用perf c2c看缓存冲突或者在两个下标之间加/不加 padding 分别跑压测对比 P99。我在调 CRingBuffer 时就是用这个方法确认为什么“明明无锁却慢得离谱”。4.3 批量接口设计从单个搬运升级为连续切片单元素push / pop接口简单但每次调用有一对 atomic 操作的固定开销。如果生产者一次性生产多条数据消费者也希望一次取一批那么批量接口的价值就很大。批量接口的设计要点是把“连续区域”暴露出来而不是逐个拷贝。环形缓冲区有一个特点可读区域可能跨过环形边界分成前后两段。我把接口设计成“申请读块”的形式typedef struct { void *seg1; size_t len1; void *seg2; size_t len2; } crb_slice_t; /* 一次申请最多 max_count 个元素返回两个连续段 */ size_t crb_read_acquire(cr_buffer_t *b, size_t max_count, crb_slice_t *slice); /* 读完提交真正推进 read_idx */ void crb_read_release(cr_buffer_t *b, size_t count);生产者侧也有对应的crb_write_reserve / crb_write_commit。拿到两段指针之后可以直接交给writev/readv做零拷贝转发或者自己按段批量 memcpy。这样固定开销从“每元素一次原子操作”降成“每批一次或两次原子操作”高吞吐路径上的效果立竿见影。4.4 预取与编译器层面的微调批量接口之外还有两个顺手可做的优化。一是利用 CPU 预取指令。消费端总是顺序读可以在读完第 N 个元素之前用__builtin_prefetch(data[(r 8) mask])去预取后面若干 cache line生产端同理。数据密集流转时预取能让内存等待时间大幅隐藏。二是保证循环里没有不可控的函数调用。比如memcpy对于小元素会被编译器内联但elem_size必须是对编译器可见的常量或结构体字段否则可能调用库函数引入额外开销。如果固定元素大小建议直接把它做成编译期常量比如往缓冲区的拷贝用memcpy(dst, src, sizeof(my_type))。5. 应用落地与实测参数从音频流到异步日志5.1 异步日志缓冲业务线程不再卡 IO日志是最典型的环形缓冲区应用。业务线程写日志如果直接写文件磁盘抖动时会把整个业务卡住。引入 CRingBuffer 后业务线程只负责把日志行拷贝进缓冲区后台专用线程批量取走并刷盘。在这个场景里我一般选“满则丢弃”策略而不是“满则阻塞”。日志本来就是采样性数据尾部少量丢失远比业务线程卡死可接受。缓冲区容量按“峰值日志速率 × 峰值持续时间”估算比如每秒钟最多产生 200MB 日志、需要撑 2 秒单条日志平均 200 字节那容量至少 200MB。用环形缓冲区时容量按字节数除以单条最大长度去换算成元素个数同时留出 2 到 3 倍余量。5.2 音频全双工链路流式数据天然适合环音频采集线程和播放线程之间传递的是固定大小的 PCM 帧。采集线程按采样率周期性写入播放线程按声卡时钟周期性读取两者时钟并不完全同步环形缓冲恰好作为吸收抖动的中间水库。容量配置有个经验值按流媒体场景缓冲区至少要能容纳 20 到 50 毫秒的音频数据。48kHz 采样率、每帧 4 字节20 毫秒大约是 960 个采样帧。设成 1024 或 2048 都合适。设太大反而会让延迟增加设太小则容易出现 underrun 或 overflow。5.3 网络收发缓冲用 IO 向量绕过两次拷贝网络收包线程把报文压入环形缓冲协议处理线程批量取走。如果缓冲区里的报文是连续存放的处理线程拿到切片后可以直接组struct iovec传给writev发送避免把分散数据先拼进一个大缓冲再发送。读侧同理readv读到两段切片后直接提交给上层协议栈省掉一次中间拷贝。吞吐越高省下来的拷贝越可观。5.4 容量与元素大小怎么定一个可套用的估算方法很多人问环形缓冲区容量到底设多大。我的估算公式很简单容量 峰值生产速率 × 允许的最大阻塞时间 / 单个元素大小然后向上取整到最近的 2 的幂再乘 2 到 3 倍的余量系数。比如生产者峰值每秒 100 万个元素允许消费者最大只延迟 5 毫秒那么缓冲区至少能撑 5000 个元素。取 8192 比较稳。元素大小影响的是总内存8192 × 256 字节 ≈ 2MB完全可接受。如果元素非常大几 KB 以上建议缓冲区只存“指针”或“偏移量”数据本体放独立的内存池。否则环形缓冲区本身的内存占用会失控拷贝大对象的开销也会成为瓶颈。CRingBuffer 的元素类型应当保持小而固定变更元素大小时重新初始化不要在运行期动态调整。5.5 压测方法与参考数据压测 SPSC 环形缓冲区建议绑核跑把生产者和消费者分别固定在两个不同的 CPU 核心上避免线程迁移干扰。我用的是clock_gettime(CLOCK_MONOTONIC)测批量 push-pop 的往返连续跑几百万次统计 P50、P99、最大延迟。一个合理的参考量级单生产者单消费者、元素 64 字节、批量 32 个元素的情况下x86 平台上的往返吞吐通常能达到每秒上千万到几千万个元素单次延迟集中在几十到几百纳秒量级。具体数值取决于 CPU、内存布局和编译优化别拿我的数字当你们机器的验收标准但相对趋势是一致的SPSC 无锁环形缓冲区的延迟分布非常紧凑基本没有离群点。5.6 开发期必须做的检查ThreadSanitizer 与统计监控无锁代码最怕改着改着引入数据竞争。我每次动 CRingBuffer 的代码都会用-fsanitizethread跑一轮压力测试。注意 ThreadSanitizer 对无锁代码的内存序只能说不撒谎但它确实能抓到大多数“真正的数据竞争”一个变量被并发读写且至少一方在写却没有被原子操作保护。另一个习惯是在缓冲区里加统计字段记录出现过多少次满、多少次空、生产者和消费者各自推进的总数。线上跑一段时间后这些数字能直接告诉你容量是否合理、生产消费速率是否匹配。有一次线上日志丢失我就是靠“满计数”字段定位到了消费线程被磁盘 IO 卡死的问题。提示无锁代码调试难维护更难。结构体改动后先跑 ThreadSanitizer再用perf看缓存争用最后再上高并发压测。顺序反了出了问题往往定位得怀疑人生。最后再分享一个我自己的习惯每次写环形缓冲区我都会先问自己这里真的需要 MPMC 吗答案绝大多数时候是不需要。分片 SPSC、或者带锁的短临界区环形缓冲区已经覆盖了 95% 以上的现实场景。CRingBuffer 最核心的价值是它用一块固定内存换掉了动态分配、用一对原子下标换掉了锁、用连续内存换掉了指针追逐。真正让它跑得飞快的不是某个玄妙的算法而是这几个朴素原则叠加在一起的效果。把每条数据路径上的固定开销降到最低延迟自然就稳了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
