上一篇文章我们把互斥锁聊透了：怎么加锁、怎么避免死锁、锁的粒度怎么控制。但锁解决的只是“互斥”，也就是同一时间只有一个人进厕所。现实里的线程协作，远不止“你别进来”这么简单，更多时候是一个线程要等另一个线程完成任务再开工——这就是“线程同步”的问题。今天这篇继续往下走，把条件变量、阻塞队列的生产者消费者模型、环形队列版本、线程池、线程安全和读写锁一口气讲完。前一篇打底的是锁，这一篇打底的是“等待与唤醒”，两者合在一起，才算把多线程协作的骨架搭起来。

我默认你已经会写 pthread_mutex_t，并且知道 lock/unlock 的基本套路。如果你连互斥锁都还没吃透，建议先把上一篇翻完再回来，不然今天讲的条件变量和锁的交互关系很容易绕晕。准备好了就开始。

1. 从互斥锁到等待唤醒：条件变量到底解决什么问题

1.1 互斥锁的天然短板：只有互斥，没有等待

先想一个特别常见的场景：一个线程往队列里塞数据，另一个线程从队列里取数据。如果用互斥锁保护这个队列，伪代码长这样：

while (1) { pthread_mutex_lock(&mtx); if (queue_empty()) { pthread_mutex_unlock(&mtx); continue; // 空转，继续抢锁 } item = queue_pop(); pthread_mutex_unlock(&mtx); handle(item); }

这段代码的问题肉眼可见：消费者线程在队列为空的时候会反复抢锁、判断、释放锁，完了再抢。这叫忙等待，对 CPU 是纯粹的浪费。更恶心的是，它还会和生产者抢同一个锁，有可能导致生产者拿不到锁，数据迟迟塞不进去，整个系统在“空转抢夺锁”上消耗大量时间片。

有人会说，那我加个 sleep 行不行？比如空转的时候睡 10 毫秒。能缓解一下，但这是拍脑袋定出来的延迟，数据到达的节奏和 sleep 根本不是对齐的。数据刚到的时候你可能还在睡，数据没到的时候你反而醒着抢锁，延迟和吞吐两头不讨好。

我们真正需要的是一种机制：消费者发现队列为空，就老老实实睡过去，不占锁也不占 CPU；生产者一旦塞入数据，能立刻把消费者叫醒。这就是条件变量存在的意义。条件变量解决的问题不是“互斥”，而是“等待与通知”。打个比方：互斥锁是厕所门锁，条件变量是“排号叫号”的系统，你不需要一直盯着柜台，轮到你时广播会通知你。

1.2 条件变量的核心 API 和调用规范

Linux 下最常用的条件变量 API 就这么几个：pthread_cond_init、pthread_cond_wait、pthread_cond_signal、pthread_cond_broadcast。当然还有带超时版本的，后面排查问题时会用到。

条件变量本身不包含状态，它必须搭配一个互斥锁使用。这是新手最容易懵的地方：为什么 wait 要传一把锁进去？看这段标准写法：

pthread_mutex_lock(&mtx); while (count == 0) { pthread_cond_wait(&cond, &mtx); } consume(); pthread_mutex_unlock(&mtx);

pthread_cond_wait做的事要拆成两步理解：

• 把mtx释放掉，让其他线程能进临界区；
• 把自己阻塞在cond上，直到被唤醒。

注意这两步是原子操作，中间不会插入其他线程的调度。为什么必须原子？如果不原子，就可能出现这种情况：你刚判断完count == 0，还没来得及睡，生产者先把数据塞进去并发了 signal，然后你才进入睡眠，信号就永久丢失了。你会一直睡到天荒地老。所以条件变量的 wait 必须“释放锁 + 挂起”一气呵成，这样才能保证“检查条件到进入睡眠”之间不会有信号漏掉。

唤醒后的行为也要注意：pthread_cond_wait返回时，锁mtx已经被重新拿到手了。所以你会看到 wait 调用通常在锁内，返回后也依然在锁内，临界区保护没有断。

1.3 为什么判断条件必须用 while，不能裸用 if

我刚学条件变量的时候也犯过这个错：直接if (count == 0) pthread_cond_wait(...)，醒来以后就往下走。结果线上偶尔出 bug，查了半天才发现是条件判断的问题。

原因有两个。第一个叫虚假唤醒（spurious wakeup）：Linux 的pthread_cond_wait文档明确说了，即使是单生产者单消费者的简单场景，也可能因为信号处理、调度等原因被唤醒但条件并不满足。第二个原因是多消费者场景：你被唤醒后，另一个消费者可能已经抢先一步把数据取走了，等你拿到锁重新跑起来时，条件又变成不满足了。

所以规范写法铁律是用 while 循环重新检查条件，不满足就继续等：

while (queue_empty()) { pthread_cond_wait(&cond, &mtx); }

这不是代码洁癖，而是正确性问题。任何讲条件变量的教程如果没强调这条，都是在埋雷。

2. 基于阻塞队列的 CP 模型：单条件变量也能跑起来

2.1 阻塞队列到底“阻塞”在哪

生产者消费者模型里，队列两侧的线程节奏往往不一样。数据生产太快、消费太慢，队列会堆满；生产太慢、消费太快，队列会空掉。阻塞队列的思路就是：队列空时消费者阻塞，队列满时生产者阻塞。队列不再是一个简单被锁保护的容器，而是自带“流量控制”语义的同步组件。

一个最精简的实现，用一个互斥锁和一个条件变量就能完成。我们先不做环形队列那种两个条件的优化，先把单条件版本跑通，搞清楚状态是怎么传递的。

2.2 单条件变量的阻塞队列设计与实现

我先写一个 C++ 版本的简单原型，关键是看 push 和 pop 如何应对“空”和“满”两个方向：

#include <pthread.h> #include <deque> template<typename T> class BlockQueue { public: BlockQueue(size_t cap) : capacity_(cap) { pthread_mutex_init(&mtx_, nullptr); pthread_cond_init(&cond_, nullptr); } ~BlockQueue() { pthread_mutex_destroy(&mtx_); pthread_cond_destroy(&cond_); } void push(const T& item) { pthread_mutex_lock(&mtx_); while (queue_.size() >= capacity_) { pthread_cond_wait(&cond_, &mtx_); // 队满，等消费者腾位置 } queue_.push_back(item); pthread_cond_signal(&cond_); // 通知可能等待的消费者 pthread_mutex_unlock(&mtx_); } T pop() { pthread_mutex_lock(&mtx_); while (queue_.empty()) { pthread_cond_wait(&cond_, &mtx_); // 队空，等生产者投喂 } T item = queue_.front(); queue_.pop_front(); pthread_cond_signal(&cond_); // 通知可能等待的生产者 pthread_mutex_unlock(&mtx_); return item; } private: std::deque<T> queue_; size_t capacity_; pthread_mutex_t mtx_; pthread_cond_t cond_; };

单条件变量版本的逻辑是：只要队列状态发生变化（从空变成非空、从满变成非满），就发一个 signal。所有线程醒来后拿锁、检查 while 条件，条件不满足就继续睡，满足就执行。这样写优势是简单，你不需要区分“空”和“满”两种事件，一个 cond 全部通知。

2.3 单条件变量方案的两个隐藏问题

第一个问题是惊群效应。如果队列里同时有多个生产者和多个消费者，pthread_cond_signal只唤醒一个线程，这本来是好事。但单条件变量的问题在于你没法精确决定唤醒的是哪一方。举个例子：队列满了，所有生产者都在等；此时消费者取走一个元素，调用 signal，系统从等待队列里挑一个线程唤醒——它有可能挑中另一个消费者。这个消费者醒来发现队列还是空的，只好继续睡。而真正该被唤醒的生产者还在等。信号被浪费了，如果极端情况下每次 signal 都唤醒错人，系统可能陷入“生产者一直等不到通知”的假死状态。

用 broadcast 全换行不行？更糟，所有线程都醒来抢锁，锁竞争激烈，绝大多数人抢到锁后条件不满足又睡回去，白白引发一轮 CPU 消耗。

第二个问题其实是设计层面的：单条件变量把“满”和“空”两种等待混在一起。从语义上讲，队列空时应该唤醒生产者去生产，队列满时应该唤醒消费者去消费，这两组人关注的是不同方向的状态变化。混用一个 cond，你就很难做定向唤醒，只能拿吞吐量换正确性。

所以在生产级别的实现里，我更推荐用两个条件变量分别表达“非空”和“非满”，也就是下面要讲的环形队列模型。

3. 环形队列的 CP 模型：两个条件变量各司其职

3.1 环形队列和阻塞队列比，优势在哪

标准库的std::deque作为任务队列确实省心，但它在高频生产消费场景下有个致命伤：队列里的元素会被反复搬运、分配和释放，内存碎片和 cache miss 会随着队列长度增加越来越明显。做高性能队列时，我一般优先考虑环形缓冲区。

环形队列本质是一个固定大小的数组，维护头尾两个下标。元素入队时写在尾部，出队时从头部取。当尾部下标追上头部时就是“满”，头部追上尾部就是“空”。因为是固定数组，不需要动态分配内存，入队出队都是 O(1)，对 cache 也很友好。

3.2 两个条件变量的分工设计

队列只有两种边界状态需要关注：

• 空：消费者不能取，必须等生产者；
• 满：生产者不能放，必须等消费者。

所以一个条件变量管“非空”（not_empty），用于消费者等待；另一个管“非满”（not_full），用于生产者等待。消费者取完元素后，只需要 signal not_full，让可能阻塞的生产者醒来；生产者放入元素后，只需要 signal not_empty，让可能阻塞的消费者醒来。谁也别乱叫醒谁，惊群概率大大降低。

这背后的原则值得多说一句：条件变量的数量应该等于需要区分的等待条件数。你等待的是“非空”还是“非满”在语义上是完全不同的两件事，合用一个变量属于偷懒。单条件变量不是不能用，但你想保证系统在复杂并发下依然高效，就必须拆开。

3.3 基于环形队列的完整实现

我写一个环形队列版的生产者消费者模型，整体结构尽量简洁，方便你直接改造成自己的组件：

#include <pthread.h> #include <vector> template<typename T> class RingQueue { public: RingQueue(size_t cap) : capacity_(cap), data_(cap), head_(0), tail_(0), count_(0) { pthread_mutex_init(&mtx_, nullptr); pthread_cond_init(&not_empty_, nullptr); pthread_cond_init(&not_full_, nullptr); } void push(const T& item) { pthread_mutex_lock(&mtx_); while (count_ == capacity_) { pthread_cond_wait(&not_full_, &mtx_); // 只等“非满” } data_[tail_] = item; tail_ = (tail_ + 1) % capacity_; ++count_; pthread_cond_signal(&not_empty_); // 只通知“非空” pthread_mutex_unlock(&mtx_); } T pop() { pthread_mutex_lock(&mtx_); while (count_ == 0) { pthread_cond_wait(&not_empty_, &mtx_); // 只等“非空” } T item = data_[head_]; head_ = (head_ + 1) % capacity_; --count_; pthread_cond_signal(&not_full_); // 只通知“非满” pthread_mutex_unlock(&mtx_); return item; } private: std::vector<T> data_; size_t capacity_; size_t head_; size_t tail_; size_t count_; pthread_mutex_t mtx_; pthread_cond_t not_empty_; pthread_cond_t not_full_; };

这个实现只有几点需要留意：

• head_、tail_、count_这三个变量都在锁内被修改，外部无锁读取的行为是未定义的，不要学网上某些写法用原子变量替代 count_ 再做无锁判空——在你没有足够内存屏障功底之前，这是给自己挖坑。
• 环形数组在写data_[tail_] = item时，如果 T 是可拷贝构造的，注意异常安全性。生产级代码应该让 T 支持移动语义，或者存储std::unique_ptr<T>这类资源句柄。
• 两个条件变量 + 定向 signal 之后，生产者不需要唤醒生产者，消费者不需要唤醒消费者，线程无效唤醒的量会明显下降。

3.4 实测时的观察要点

把队列容量设成 1，你会看到生产者和消费者严格交替执行，这时能直观验证两个条件变量是否正确协作。再把容量调大，比如 1024，放 4 个生产者、4 个消费者同时跑，观察吞吐量。

我自己的习惯是写一个带时间戳的压测脚本，统计每秒钟成功 push 和 pop 的次数。对比单条件变量版本，两个条件变量版本在 8 线程以上时吞吐提升通常在 20% 到 40% 之间，线程数越多差距越明显。如果你的测试结果相反，优先检查是不是你的临界区里还做了别的耗时操作，比如打印日志，或者 push 时不小心 copy 了大对象。

4. 线程池：把条件变量、互斥锁、任务队列组装成生产级组件

4.1 为什么需要线程池

每次需要处理任务就pthread_create一个线程，用完再pthread_join销毁？这在任务量小的时候没问题，但任务一来就是几千个的时候，线程创建销毁的开销会占到总耗时的相当比例。线程创建涉及内核分配栈空间、建立调度实体，销毁还要回收，这些都是真金白银的成本。

线程池的思路是：预先创建好一组线程，不销毁，不断从任务队列里取任务执行。线程本身是复用的，任务队列负责流量缓冲。线程池三件套就是：任务队列、互斥锁、条件变量，外加一个工作线程数组。这正好把我们前面讲的所有同步原语串起来了。

4.2 一个可用的线程池骨架

设计线程池时，我会把“任务执行”放到锁外。为什么？任务本身可能耗时很长，如果放在锁内执行，其他线程想投递任务会被锁挡住，整个池子的并发能力会崩塌。更严重的是，任务内部如果再尝试往同一个池子投递任务，可能出现死锁：持有锁的任务在等锁，另一个持有锁的投递线程又在等第一个任务释放锁，互相卡死。

骨架大概是这样的结构：

#include <pthread.h> #include <queue> #include <vector> #include <functional> class ThreadPool { public: ThreadPool(int threads) : shutdown_(false) { pthread_mutex_init(&mtx_, nullptr); pthread_cond_init(&cond_, nullptr); workers_.reserve(threads); for (int i = 0; i < threads; ++i) { pthread_t tid; pthread_create(&tid, nullptr, worker_func, this); workers_.push_back(tid); } } void submit(std::function<void()> task) { pthread_mutex_lock(&mtx_); tasks_.push(std::move(task)); pthread_cond_signal(&cond_); pthread_mutex_unlock(&mtx_); } void shutdown() { pthread_mutex_lock(&mtx_); shutdown_ = true; pthread_cond_broadcast(&cond_); pthread_mutex_unlock(&mtx_); for (auto tid : workers_) { pthread_join(tid, nullptr); } } private: static void* worker_func(void* arg) { ThreadPool* pool = static_cast<ThreadPool*>(arg); pool->work_loop(); return nullptr; } void work_loop() { while (true) { std::function<void()> task; { pthread_mutex_lock(&mtx_); while (tasks_.empty() && !shutdown_) { pthread_cond_wait(&cond_, &mtx_); } if (shutdown_ && tasks_.empty()) { pthread_mutex_unlock(&mtx_); return; } task = std::move(tasks_.front()); tasks_.pop(); pthread_mutex_unlock(&mtx_); } task(); // 关键：任务必须在锁外执行 } } std::queue<std::function<void()>> tasks_; std::vector<pthread_t> workers_; pthread_mutex_t mtx_; pthread_cond_t cond_; bool shutdown_; };

工作线程的执行逻辑可以用一句话概括：没有任务就睡，有任务就抢，拿到任务先释放锁再执行。任务投递方的逻辑更简单：加锁、塞队列、发通知、解锁。

4.3 销毁线程池的规范流程

线程池销毁是很多人容易翻车的地方。直接pthread_cancel工作线程？我劝你别这么干，容易造成任务执行一半被中断，资源没来得及释放。规范的销毁流程是：

1. 设置shutdown_ = true；
2. pthread_cond_broadcast唤醒所有阻塞在条件变量上的工作线程；
3. 逐一pthread_join回收线程；
4. 保证队列里残留的任务要么被丢弃，要么由某个线程执行完再退出。

工作线程退出前必须重新加锁，再检查shutdown_ && tasks_.empty()，这是因为可能会有“你刚把任务塞进队列，还没 signal，shutdown 就把大家全叫醒”的情况。如果 workers 醒来发现队列里有任务，哪怕 shutdown 已经置位，也应该先把任务执行完再退，否则任务会静默丢失。

4.4 线程数到底设多少合适

这是一个老生常谈的问题。CPU 密集型任务，线程数一般设为核数 + 1；IO 密集型任务，因为线程经常阻塞在 IO 上，可以多一些，常见经验值是核数 * 2左右。但真实系统里任务往往混合了 CPU 和 IO，所以我更建议直接做一次压力测试，先设 4、8、16、32 跑一轮，观察吞吐量和响应延迟，找到拐点。

线程池的大小还会影响条件变量的竞争程度。池子过大，任务队列很短时，线程们就会频繁空转抢锁。我曾经在一个网络服务里把线程池从 32 改成 16，吞吐反而高了 15%，就是因为锁竞争减少了。所以“池子越大越好”这个直觉，在并发场景下经常是错的。

5. 线程安全：锁只是手段，不是银弹

5.1 线程安全到底在说什么

很多人把“线程安全”等同于“加锁”，其实远远不止。线程安全指一段代码在多线程并发调用下，仍然能维持正确的状态和可预期的结果。它的三个基础维度是：原子性、可见性、有序性。

原子性说的是一个操作不可被线程调度打断。比如count++在 CPU 指令层面就不是原子的，多个线程同时执行它就会互相覆盖。互斥锁能保证临界区的原子性，但原子性不一定必须靠锁，原子变量也可以。

可见性说的是一个线程修改了数据，另一个线程能不能立刻看到。CPU 有缓存，编译器有优化，你在这边改了变量，另一个核上的线程可能读到的还是旧值。这就是为什么锁释放后，其他线程能立刻看到最新状态——锁的实现自动带了内存屏障。

有序性更隐蔽：为了性能，编译器和 CPU 都可能重排指令。单线程下没问题，多线程下就可能产生意外顺序。所以为什么“不加锁的共享变量”很难写对，就是因为这三个维度都难以保证。

5.2 “不加锁”也能线程安全的情况

在动手加锁之前，先问自己：这个数据真的需要锁吗？如果它是只读的，比如初始化后不变的路由表，完全可以不加锁，所有线程并发读就行。如果它只在某个线程内部使用，那就做成局部变量，或者搞一个线程局部存储，根本不共享，也谈不上安全。

我再强调一种值得刻意使用的思路：所有权转移。生产者创建了一个任务对象，把它塞进队列；消费者从队列里取出来它的“所有权”，用完后销毁。在整个生命周期里，一个对象同时只有一个线程持有。这样你不需要给对象本身加锁，只需要保护队列的入队和出队操作。这是非常多高性能服务里常用的做法。

5.3 volatile 背不了锁的锅

我见过不少新手拿volatile当线程安全工具用，把共享变量都标成 volatile，以为就万事大吉了。volatile 确实能告诉编译器不要优化掉这个变量的读写，但它不能保证 CPU 缓存之间的可见性，也不能保证操作的原子性。两个线程同时对 volatile 变量做++，照样丢更新。

真的需要无锁读写的场景，请用 C++11 的std::atomic，或者 Linux 的__atomic内建函数。至少要知道：只有原子变量的读写才是安全的，普通变量即使加了 volatile 也不行。

5.4 排查线程安全问题的经验

线程安全问题的特点是难复现。数据竞争往往在特定调度顺序下才触发，你调试时跑得好好的，上线后偶发崩溃。我的排查思路是这样的：

• 先开线程消毒器（ThreadSanitizer），它能检测数据竞争，编译时加-fsanitize=thread，跑一轮压力测试，通常会直接报出有竞争的行号。
• 再看崩溃栈，如果崩溃点在一个看起来“不可能空”的指针上，九成是别的地方数据竞争把内存写坏了，顺着共享变量往上查。
• 最后复盘设计：有多少变量是跨线程共享的？这些变量是不是都有明确的锁保护？有没有可能通过所有权转移或不可变设计消除共享？想清楚这三点，再加锁也来得及。

6. 读写锁：读多写少场景下的第一选择

6.1 互斥锁把读和写一视同仁，太浪费了

假设你有一个配置表，几十个线程都在读，只有极少数时刻有一个线程去更新。如果全用互斥锁，每个读者都要和其他读者互相排斥，明明读操作不改数据，却被逼着串行执行，并发能力白白浪费了。

Linux 提供的pthread_rwlock_t就是为了解决这类场景：允许多个读者同时持有读锁，但写锁是排他的，写锁持有期间没有任何读者或写者能进入临界区。符合直觉的说法是：读读共享、读写互斥、写写互斥。

基本用法不复杂：

pthread_rwlock_t rwlock; // 读路径 pthread_rwlock_rdlock(&rwlock); // 读取共享数据 pthread_rwlock_unlock(&rwlock); // 写路径 pthread_rwlock_wrlock(&rwlock); // 修改共享数据 pthread_rwlock_unlock(&rwlock);

6.2 读写锁也会踩坑：写者饥饿与锁升级

用读写锁之前必须知道一个致命缺陷：不同实现的调度策略不一样。有的实现是读者优先，只要不断有读者到来，写者就可能一直等不到锁，这叫写者饥饿。某些实现里，线程无法保证在持有读锁的情况下安全升级为写锁，因为如果两个读者同时想升级，就会互相等对方释放读锁，死锁。所以绝对不要在一个线程内先 rdlock 后直接 wrlock，要么统一用写锁，要么先解锁再重新请求写锁，但要接受中间状态可能被其他读者看到。

我在实际项目里遇到过更隐蔽的问题：超过一定线程数后，读写锁的性能甚至不如互斥锁。原因是读写锁内部需要维护读者计数，这本身就有原子操作和缓存一致性开销。如果临界区很短，读者频繁加锁解锁，原子操作的开销就可能大于锁竞争的开销。所以我建议用读写锁前先做个性能对比，别想当然。

6.3 读多写少更优雅的替代方案：Copy-On-Write

在某些场景下，连读写锁都不需要。比如一份配置数据，读者很多，写者很少，我常用的方案是读写加引用：

• 写者先把旧数据复制一份，在副本上修改；
• 然后用原子操作替换掉指向数据的指针；
• 读者通过原子加载拿到当前指针，读取数据。

只要读者拿到指针后不再等待新版本，老版本在最后一个读者释放引用前不会被回收。这是典型的无锁读优化，比读写锁更适合“读频率超高、写频率极低”的场景。

这个方案有一个前提：数据本身是可复制且比较小的，复制成本你承受得起。如果是一个巨大的缓存哈希表，每次写都复制整个表，代价可能比读写锁还高。所以还是要分场景，没有银弹。

6.4 读写锁适用性自查清单

我给自己总结了四个条件，满足才考虑用读写锁：

• 读操作远多于写操作，比例至少 10:1；
• 每次持有读锁的时间比加锁本身的开销长得多；
• 临界区的读操作真的不会修改数据；
• 写操作频率不高，但发生时能接受一定程度地阻塞读者。

如果这四条里有一条不满足，老老实实用互斥锁，或者干脆走无锁路线，别让读写锁的理论优势骗了你。

7. 常见问题速查表与避坑清单

7.1 典型问题与排查方向

我在各种项目里反复遇到过的问题，整理成一张表，你排查的时候可以对号入座。

7.2 条件变量使用的七个铁律

最后分享我在实际调试中总结出来的一套条件变量使用纪律，每次写代码都对照一遍：

1. 条件变量的等待必须放在锁内；
2. 条件判断必须用 while，不能用 if；
3. 只要修改了条件相关的共享状态，就必须发送对应信号；
4. signal 和 broadcast 都要在锁内或锁外调用？可以在锁外调用，但必须在修改共享状态后调用；
5. 一个条件变量对应一种等待语义，别混用；
6. 唤醒后必须重新检查条件再往下走；
7. 程序退出前必须唤醒所有等待者，否则线程会一直挂起。

如果你能用好互斥锁解决“互斥”，再用条件变量解决“等待”，把阻塞队列和环形队列的 CP 模型吃透，最后把线程池封装成顺手的基础组件，Linux 多线程开发就算是真正入门了。至于读写锁和线程安全，更多是设计层面的权衡——你知道得越多，越明白锁不是越多越好，而是越精准越好。

我个人在实践里总把这句话挂在嘴边：能用“所有权转移”解决，就不加锁；能用“无锁读”解决，就不用读写锁；必须加锁时，再想条件变量怎么配。多线程程序的复杂度和你能意识到的并发问题数是成正比的，把所有隐藏的共享状态都摆到桌面上来，很多奇奇怪怪的崩溃都能在写代码阶段就避免掉。

希望你读完这篇，不只是记住了几个 API，而是能在下一次写多线程模块时，先把“谁在等、谁唤醒谁、条件怎么判断”这三件事想明白。这套思路用熟了，比你背口诀管用得多。