1. 为什么并发编程绕不开线程安全队列做了几年后端和中间件我越来越觉得线程安全队列就是并发编程里的“九九乘法表”。你去看线程池的任务调度、日志异步落盘、数据管道、生产者消费者模型核心就是一张队列在扛事。不信你打开任何一门语言的标准库Java 有BlockingQueue和ConcurrentLinkedQueueC 有std::queue配互斥锁的经典组合Go 干脆把 channel 做成了语言特性。这个数据结构太基础了以至于新人容易低估它老手又容易在细节上翻车。先说清楚线程安全队列到底在解决什么问题。单线程环境下队列就是一个 FIFO 容器push进队尾pop出队头逻辑清清楚楚。但一旦有两个以上线程同时操作同一个队列问题立刻冒出来线程 A 正在push线程 B 同时pop它们的操作会交叉执行程序看起来每一行代码都是原子的实际上从 CPU 指令层面看一条queue.push(x)可能要经过取指针、改链表节点、更新尾部指针好几次读写操作中间任何一步被打断队列的内部状态就坏了。典型症状是数据丢失、读到空值、程序崩溃最气人的是这种 Bug 不是必现的可能压测半天才冒出来一次难查得要命。那是不是加个锁就完事了是但不完全是。加锁如果加得不讲究死锁、饥饿、性能崩盘都会找上门。我见过不少同事写的“线程安全队列”线程是安全了但吞吐量比单线程还差生产线程和消费线程互相拖后腿压根没法用。这就是为什么我想把这篇文章整理出来把加锁方案、有界环形队列、无锁方案从头到尾过一遍重点讲清楚每个设计决策背后的原因。不管你是刚接触多线程的初学者还是写过几年并发代码想补补底层细节的老手照着这篇文章的思路走一遍自己对队列的掌控力会明显不一样。文章后面会有可以直接拿去用的 C 实现也有压测数据和踩坑记录。我尽量不堆术语遇到必须用的概念就用大白话解释确保你在自己的机器上能把代码跑起来也能真正理解每一行为什么这么写。2. 线程安全队列的设计思路与方案选型2.1 两派路线加锁与无锁线程安全队列的主流实现路线就两大派锁派和无锁派。锁派靠互斥锁或读写锁保证同一时间只有一个线程能改动队列逻辑直观心智负担低无锁派则基于 CAS比较交换原子操作让多个线程同时推进谁冲突谁重试理论上没有阻塞扩展性更好。就我自己的经验选哪一派不取决于谁的“噱头”大而取决于你的业务场景和团队水平所以这里把两派的基本面拆开讲一下。加锁方案可以细分为“互斥锁加条件变量”和“互斥锁加信号量”两种常见组合。核心思想是用一把锁保护队列的所有读写线程进来之前先尝试拿锁拿不到就排队等操作完成之后释放锁并通知等待中的线程“队列状态变了你可以继续了”。这种方案的好处是正确性容易证明——你在锁内把队列从头到尾维护成一致状态外界永远看不到中间状态。无锁方案的核心是 CAScompare_exchange_strong或者compare_exchange_weak它会原子地比较一个内存地址的当前值是否等于期望值如果相等就替换成新值如果不相等什么都不做。你的代码要做的事情就是循环重试比如“我想把队尾指针从 A 改成 B”如果发现当前队尾已经不是 A 了说明别的线程抢先改了那就重新读取最新的队尾再试一次。听起来简单但一旦要考虑内存序、ABA 问题、节点内存回收复杂度立刻上几个台阶。我见过不少团队一上来就想炫技搞无锁队列结果半年之后还在修内存回收的 Bug。有一个很现实的经验如果你的队列只需要应对“每秒几万次读写”加锁方案完全够用性能余量还很足如果你的目标是“每秒几十万甚至上百万次”并且你愿意投入时间做正确的内存管理和大量压测无锁方案才值得考虑。2.2 有界队列 vs 无界队列这不是选择题是判断题队列到底该设不设容量上限很多人写第一版线程安全队列时根本没想过这个问题直接拿std::queue无限 push结果生产速度一旦超过消费速度内存就一路涨上去最后把进程活活撑死。有界队列和无界队列各有利弊。无界队列实现简单生产者永远不会被阻塞推数据就完事但代价是消费速度跟不上时积压数据会无限增长系统内存占用与延迟双双失控。有界队列正好相反它给队列设定了一个最大容量满了之后要么让生产者阻塞等待要么直接丢弃任务配合丢弃策略这其实就是一种背压机制。在真实系统里背压不是可选项而是必需品下游数据库写慢了内存队列就应该让上游也慢下来而不是默默把所有请求都吞进肚子。从模型上讲线程池、消息中间件、日志缓冲这些场景几乎都应该选有界队列。容量设置多少要看业务容忍度容量太小生产者频繁等待吞吐上不去容量太大某次消费抖动能被吸收但极端情况下延迟依然很高。你需要根据平均消费耗时、峰值生产速率和可接受的最长排队时间来计算合适容量。2.3 无锁队列的底层原理CAS 与内存序说到无锁队列很多人第一反应是“快”但它的真正价值不是快而是“可扩展”。在高并发场景下锁的本质是让线程排队排队意味着竞争竞争意味着上下文切换和缓存抖动线程一多吞吐量反而上不去。无锁队列让每个线程都试着往前推进冲突时原地重试线程越多CPU 的核心利用率越高。无锁队列的标准鼻祖是 Michael 和 Scott 在 1996 年提出的 MS 队列核心结构是一个带哑结点的单向链表。头指针指向哑结点尾指针指向最后一个有效结点。入队时先创建一个新结点然后循环尝试用 CAS 把尾指针的 next 从空改成新结点改成功了再尝试把尾指针后移出队时循环尝试用 CAS 把头指针从当前哑结点移到下一个结点。这个算法看起来很简洁但工程上最难的有两点。其一是内存序多核 CPU 并不是严格按照你代码的顺序执行读写它有自己的缓存和重排规则你必须用 acquire、release、relaxed 这些内存序标注来告诉 CPU “这里不能乱序”。其二是内存回收出队时把旧的头结点从链表上摘下来了但另一个线程可能还持有指向这个结点的指针直接 delete 就会踩到野指针这就是无锁编程中最著名的坑。2.4 方案选型场景决定一切我整理了一张选型表你在动手写代码前可以先对照一下场景特征推荐方案理由功能优先读写量不大团队经验一般互斥锁 条件变量正确性最容易保证代码可读性好高吞吐、有界缓冲、读写均衡互斥锁 环形缓冲区缓存友好无动态内存分配性能稳定单一生产者、单一消费者无锁 SPSC 环形队列几乎零开销内存序简单实现难度低多生产者、多消费者超高性能要求成熟的第三方无锁队列MS 队列内存回收极难做对别自己造轮子对延迟抖动极其敏感无锁或有锁但低竞争方案锁的争抢会导致尾部延迟飙升选型没有标准答案只有“合不合适”。我自己的原则是默认从互斥锁开始先跑通功能再做性能测试测试数据说话如果锁竞争确实成了瓶颈再考虑环形缓冲、SPSC、或者引入成熟的无锁库。因为大部分业务系统的性能瓶颈根本不在队列本身而在业务逻辑里的 IO 和计算过早优化反而浪费时间。3. 实操从零手写三版线程安全队列3.1 第一版互斥锁 条件变量实现无界队列先给一个最经典的版本它使用std::mutex保护队列状态用std::condition_variable协调生产者和消费者的等待与唤醒我直接贴完整代码并逐段解释。#include queue #include mutex #include condition_variable template typename T class SafeQueue { public: void push(T value) { { std::lock_guardstd::mutex lock(m_mutex); m_queue.push(std::move(value)); } m_notEmpty.notify_one(); } T pop() { std::unique_lockstd::mutex lock(m_mutex); m_notEmpty.wait(lock, [this]() { return !m_queue.empty(); }); T value std::move(m_queue.front()); m_queue.pop(); return value; } bool tryPop(T value) { std::lock_guardstd::mutex lock(m_mutex); if (m_queue.empty()) { return false; } value std::move(m_queue.front()); m_queue.pop(); return true; } private: std::mutex m_mutex; std::condition_variable m_notEmpty; std::queueT m_queue; };这里有几个细节值得多说两句。第一push里为什么用花括号把加锁区单独框起来因为notify_one本身不需要锁先释放锁再通知消费者拿到锁的概率更高可以减少无谓的锁竞争。第二pop里为什么不直接wait而是用带谓词的重载形式因为条件变量存在“虚假唤醒”系统有可能在没有任何人通知的情况下把线程唤醒如果唤醒后直接取队首队列是空的就会出问题。带谓词的写法本质是一个循环唤醒后先检查条件不满足就继续睡这条规则是条件变量使用的铁律。第三tryPop提供非阻塞的出队能力。它在队列为空时立刻返回 false适合那些不想让消费者无限期等待的场景比如定时批量清空任务。std::lock_guard和std::unique_lock的区别在于前者只能保证加锁和解锁后者可以配合条件变量在等待时临时释放锁这部分是条件变量能工作的关键。3.2 第二版有界环形队列应对背压与高吞吐第一版功能没问题但有两个天然短板无界导致内存隐患std::queue每次 push 都可能分配堆内存。第二版我会用一块预分配的环形缓冲区解决这两个问题。#include vector #include mutex #include condition_variable #include stdexcept template typename T class RingBufferQueue { public: explicit RingBufferQueue(size_t capacity) : m_capacity(capacity), m_buffer(capacity) {} void push(const T item) { std::unique_lockstd::mutex lock(m_mutex); m_notFull.wait(lock, [this]() { return !isFull(); }); m_buffer[m_head] item; m_head (m_head 1) (m_capacity - 1); m_notEmpty.notify_one(); } bool tryPush(const T item) { std::lock_guardstd::mutex lock(m_mutex); if (isFull()) { return false; } m_buffer[m_head] item; m_head (m_head 1) (m_capacity - 1); m_notEmpty.notify_one(); return true; } T pop() { std::unique_lockstd::mutex lock(m_mutex); m_notEmpty.wait(lock, [this]() { return !isEmpty(); }); T item m_buffer[m_tail]; m_tail (m_tail 1) (m_capacity - 1); m_notFull.notify_one(); return item; } bool tryPop(T item) { std::lock_guardstd::mutex lock(m_mutex); if (isEmpty()) { return false; } item m_buffer[m_tail]; m_tail (m_tail 1) (m_capacity - 1); m_notFull.notify_one(); return true; } private: bool isFull() const { return m_head m_tail - 1 || (m_head m_capacity - 1 m_tail 0); } bool isEmpty() const { return m_head m_tail; } size_t m_capacity; std::vectorT m_buffer; size_t m_head 0; size_t m_tail 0; std::mutex m_mutex; std::condition_variable m_notEmpty; std::condition_variable m_notFull; };环形队列的核心思想是数组头尾相接用 head 表示下一个写入位置用 tail 表示下一个读取位置。队列空的时候 head 等于 tail队列满的时候需要额外判断。我这里的判断方式是“牺牲一个槽位”即最多存储 capacity-1 个元素这样满和空的判断就不会混在一起。需要特别提醒的是容量参数。上面代码里我用 (m_capacity - 1)代替取模运算这个技巧只有在容量是 2 的幂时才成立比如 1024、4096。为什么用位运算因为取模操作在 CPU 层面是除法耗时钟周期多而位与操作是单周期指令在高频读写场景下积少成多差距明显。如果你的容量不是 2 的幂要么老老实实改成% m_capacity要么在初始化时做校验直接抛异常否则会踩到数组越界的坑。3.3 第三版单生产者单消费者的无锁环形队列接下来是进阶内容真正的无锁实现。不过我不打算直接上多生产者多消费者的 MS 队列因为那涉及复杂的 CAS 循环和内存回收工程上极其容易出错。我先把 SPSC单生产者单消费者场景讲透这是无锁队列里最实用也最可行的一个分支。#include atomic #include vector template typename T class SpscQueue { public: explicit SpscQueue(size_t capacity) : m_capacity(capacity), m_buffer(capacity) {} bool push(const T item) { size_t head m_head.load(std::memory_order_relaxed); size_t nextHead (head 1) (m_capacity - 1); if (nextHead m_tail.load(std::memory_order_acquire)) { return false; // full } m_buffer[head] item; m_head.store(nextHead, std::memory_order_release); return true; } bool pop(T item) { size_t tail m_tail.load(std::memory_order_relaxed); if (tail m_head.load(std::memory_order_acquire)) { return false; // empty } item m_buffer[tail]; m_tail.store((tail 1) (m_capacity - 1), std::memory_order_release); return true; } private: size_t m_capacity; std::vectorT m_buffer; alignas(64) std::atomicsize_t m_head{0}; alignas(64) std::atomicsize_t m_tail{0}; };这个实现能无锁跑起来的前提是只有一个生产者和一个消费者所以 head 只被生产者写tail 只被消费者写不存在两个线程同时修改同一个变量的竞争。用到的两个核心内存序是 release 和 acquire生产者写入数据之后再 release 更新 head消费者 acquire 读取 head保证“看到 head 更新时缓冲区里的数据一定已经写完”反过来也同理。alignas(64)是防伪共享的关键。CPU 缓存行通常 64 字节如果 head 和 tail 恰好落在同一个缓存行里生产者每次更新 head 都会导致消费者持有的缓存行失效即使两者逻辑上完全无关。把它们分别对齐到不同的缓存行之后读写互不干扰性能能差出一个数量级。为什么说有界环形结构特别适合无锁化因为整个队列就是一个固定大小数组不存在动态分配和释放单个结点的需求天然避开了无锁编程里最头疼的内存回收问题。如果你的系统恰好是单生产者单消费者模型比如网络收发线程、音视频处理管线这套实现就是性价比最高的选择。3.4 测试与验证怎么证明你的队列真的线程安全队列写完不是能跑就完事了你得证明它在多线程环境下不丢数据、不错乱。我常用的验证套路分三步前两步必须做第三步看场景。第一步是在高并发下做正确性测试。创建 4 个生产者线程每个往队列塞 100 万个从 0 到 999999 的整数同时创建 4 个消费者线程把取出来的数累加到一个共享变量上最后检查总和是否等于 4 个线程各自累加值的总和。如果队列有问题总和一定会对不上而且跑的次数越多越容易暴露。第二步是压力和延迟测试。用一个原子计数器统计完成 100 万次 push 和 pop 的总耗时测出吞吐量同时记录每次 pop 的耗时分布重点看 p99 和 p999 的延迟。队列这类组件平均延迟好看没有用尾部延迟才是用户体验和系统稳定性的真实写照。第三步如果条件允许用 ThreadSanitizer 或竞态检测工具跑一遍。C 编译时加-fsanitizethread它能自动帮你发现数据竞争虽然会有一定性能开销但排查并发问题确实高效。我做这类验证时有一个额外心得先别开编译器优化用 debug 模式跑正确性测试再开-O2跑性能和竞态检测。因为优化会改变指令重排的程度很多潜在问题在 debug 模式下根本不会出现这样两步都过了才能真正放心把队列放进生产代码。4. 性能实测数据会告诉你该选哪种方案4.1 实测数据对比三种方案的真实差距我这套测试环境是 8 核 16 线程的 x86 机器C 编译开-O2。测试内容是 4 个生产者线程和 4 个消费者线程总共传输 200 万条消息记录每秒完成的 pushpop 对数。# 编译命令 g -O2 -stdc17 -pthread queue_bench.cpp -o queue_bench测出来的结果大概是这样具体数值因机器而异重点看相对关系方案吞吐量万次/秒特点互斥锁 std::queue无界80~120实现简单线程多时竞争激烈互斥锁 环形缓冲有界 1024200~350缓存友好度提升明显SPSC 无锁环形队列800~1500无锁无竞争缓存友好第三方 MPMC 无锁库400~700性能和扩展性的平衡点无界std::queue的吞吐量上不去很大程度是因为每次 push 都在堆上 new 新节点内存分配器和缓存都要跟着遭殃环形缓冲因为内存是预分配且固定大小的读写局部性好CPU 缓存命中率高SPSC 则完全没有锁竞争两个索引各自更新性能自然一骑绝尘。4.2 队列容量和线程数量怎么影响吞吐队列容量对吞吐量的影响是典型的边际递减曲线。容量太小生产者频繁撞到“满”从而等待吞吐上不去容量太大队列里堆积的数据变多消费者读到的数据新鲜度下降而且缓存命中率也可能下滑。我测过 64、1024、8192 三档容量1024 在很多场景下已经够用8192 提升不到一成但内存占用是 8 倍。线程数量也值得聊一聊。加锁队列在线程数超过 CPU 核心数之后吞吐量不升反降因为锁竞争导致大量线程在排队等待上下文切换开销超过了新增线程的收益。无锁队列在核心数以内都能保持线性扩展超过核心数之后进入平台期不会像锁那样崩得厉害。这个特性让无锁队列在“消费者偶尔阻塞、生产者持续生产”的流量模型下特别吃香。4.3 延迟抖动比吞吐量更隐蔽的性能杀手吞吐量高不代表系统可靠。我用 100 万次 pop 的耗时分布做了一个统计加锁方案的 p99 通常在几十微秒但如果某个线程被调度器切走锁持有的时间变长p999 可能跳到几百微秒甚至毫秒级。这类尾部延迟在高频交易、实时音视频、游戏服务端里都是致命的。无锁方案的尾部延迟要稳定得多因为它没有线程被阻塞等待锁这个过程每次 pop 要么成功要么直接返回“空”重试也只在极端竞争下发生。这不意味着无锁一定延迟更低只是它的延迟分布更集中更可预测。如果你的业务对“最大延迟”有硬性要求SPSC 无锁队列是我最推荐的起点。5. 常见问题与排查技巧实录5.1 死锁最隐蔽也最致命的坑线程安全队列的第一大杀手是死锁。我用几行代码就能演示出问题一个线程先持有了队列 A 的锁又去拿队列 B 的锁另一个线程反向操作先拿 B 再拿 A两个线程互相等对方释放锁程序就永远停在那里了。更隐蔽的是“持锁等待”。比如在pop返回 T 之后你还在锁内调用一个可能阻塞的函数比如网络发送或者磁盘写这把锁就被你霸占了其他线程全部排队。正确做法是尽量缩小临界区只把队列操作的几行放在锁内拿到数据之后立刻释放锁再做耗时业务。还有一个我的亲身教训异常会造成锁不释放。如果在push执行过程中std::queue自己抛出了bad_alloc而你没有用 RAII 方式管理锁锁就永远留在加锁状态所有线程全部挂起。所以用std::lock_guard和std::unique_lock这类 RAII 锁是底线绝不要手动lock和unlock成对出现却不管异常路径。5.2 虚假唤醒与丢失唤醒条件变量有两个非常出名的问题虚假唤醒和丢失唤醒。虚假唤醒是系统层面的问题线程可能在没有任何 notify 的情况下醒过来。解决方式就是我们在第一版代码里用到的带谓词的wait它会在唤醒后重新检查队列状态不满足就继续睡。丢失唤醒则是程序员自己的问题。最常见的一种写法是if (queue.empty()) { m_notEmpty.wait(lock); }假设队列为空消费者进入 if 判断正准备 wait。此刻生产者 push 了一个数据调用notify_one但消费者还没真正进入 wait 状态这个通知就丢了。然后消费者继续执行 wait但队列可能一直没新数据进来它就会永远等下去。正确的姿势是每次都把wait放进循环让谓词检查成为唯一判断依据这样通知丢失也能在下次唤醒时重新检查。5.3 ABA 问题与无锁内存回收无锁队列里的第二个大坑是 ABA。举个例子线程 A 读到了队尾指针 P准备用 CAS 把 P 从值 V 改成新值。在它 CAS 之前线程 B 先把 P 弹出删掉又新建了一个结点恰好分配到同一地址然后把这个新结点链接回队列。线程 A 的 CAS 一看地址还是 V以为自己一直没被干扰于是修改成功。实际上队列的链条已经被改动过了这个 CAS 让整个队列结构错乱。解决 ABA 的办法有几种给每个指针附带一个版本号CAS 时同时比较版本号或者用 hazard pointer 保证结点不会被立即回收。这些技术都很难所以我反复强调非必要不要自己造无锁队列。业界成熟的实现早就把内存回收问题处理好了你直接调用就好。5.4 缓存伪共享性能杀手伪共享是性能问题但非常隐蔽。多核 CPU 的缓存是以缓存行通常 64 字节为单位加载的如果两个线程频繁访问的变量恰好落在同一个缓存行里即使它们逻辑上毫不相关每次修改其中一个变量另一个变量所在的缓存行也会失效导致另一个线程必须重新从内存加载。在我前面 SPSC 的代码里m_head和m_tail如果紧挨着放生产者改 head 就会干扰消费者读 tail性能可能直接掉一半以上。用alignas(64)把它们隔开是标准解法。这个坑不只出现在队列里任何高并发下被不同线程同时读写的变量都应该检查缓存行对齐。5.5 排查工具和我的实战顺序真遇到线程安全队列的问题我的排查顺序是这样的第一步先看是否是死锁。用gdb附加到卡住的进程执行thread apply all bt如果看到多个线程停在__condvar_wait或者__lll_lock_wait八成是死锁接着检查它们各自持有的锁找循环等待关系。第二步检查是否丢数据。看消费者收到的总条数是否和生产者发出的总条数一致不一致优先怀疑丢失唤醒或者队列状态维护有误。第三步用 ThreadSanitizer 跑一遍它能直接告诉你哪两个线程在哪个地址发生了数据竞争连代码行号都给出来省去大量猜谜时间。如果以上都查不出来把并发量降级改为单生产者单消费者重压测试再加回完整的生产者消费者模型。逐步缩小问题范围比盯着一大团日志盲猜高效得多。6. 工程化落地别重复造轮子6.1 哪些场景必须自己写哪些场景直接上库手写线程安全队列非常能锻炼并发思维但生产环境要克制。如果你的场景就是需要一个简单的任务队列std::mutex加std::condition_variable的组合实现一百行不到自己维护毫无压力如果性能要求高但人力有限成熟库几乎是唯一理性选择。几款常用的库我简单点评一下Boost 的boost::lockfree::queue是经典的 MPMC 无锁队列文档全社区广适合不想引入大型依赖但对无锁有兴趣的团队Intel TBB 的concurrent_queue和concurrent_bounded_queue和线程池配合得很好在有界并发队列场景下表现优秀moodycamel 的ConcurrentQueue一直是我个人比较偏爱的一款它在多生产者多消费者场景下的性能和内存占用都控制得很好而且只依赖标准库接入成本低。6.2 如何改造队列以适配你的业务生产环境的队列需求通常不是裸的 push/pop你需要做一些封装。我常用的三个增强功能是关闭标志、批量出队、优先级支持。关闭标志是优雅停机的关键。消费者线程不能永远pop阻塞在队列上当系统要关闭时你需要一个shutdown标志和条件变量配合让消费者从wait中醒来并退出循环。批量出队则是性能优化利器消费者一次取出 N 条消息再统一处理减少锁的获取次数特别适合消息合并写入的场景。优先级支持通常是在队列内部维护多个桶出队时按优先级依次取但要注意公平性避免低优先级任务被饿死。6.3 关于线程安全队列我最后想说的话写线程安全队列这十几年我最深的一个体会是并发问题的难度从来不在于“加锁”这个动作本身而在于你愿不愿意把每一个细节都想透彻。为什么条件变量必须配谓词为什么有界队列必须考虑背压为什么无锁队列的内存回收比 CAS 本身还难这些问题背后涉及的是操作系统调度、CPU 缓存、内存模型这些最底层的机制。你每搞懂一个为什么就相当于给自己的并发知识体系填了一块地基下次遇到别的并发问题也能触类旁通。最近几年我写队列代码时越来越“保守”了能加锁就加锁能用 SPSC 就不碰 MPMC能上库就不自己造。不是因为我不会写无锁队列而是因为生产系统最贵的从来不是那点性能是排障时烧掉的精力和事故造成的损失。但如果你真的想深入并发编程我依然强烈建议你亲手写一遍这三种队列哪怕只在自己的学习项目里跑一跑。纸上得来终觉浅这句话放在并发领域再合适不过。