线程同步深度解析：条件变量与POSIX信号量核心原理及实战

1. 线程同步的下半场：为什么互斥锁不够用

1.1 轮询加锁的最大问题不是性能

很多新手写多线程代码，第一步能想到的永远是pthread_mutex_lock和pthread_mutex_unlock。互斥锁能保证临界区不被打断，这没错，可一旦遇到“某个条件满足后再继续干活”的场景，比如生产者没放数据，消费者就不该去拿，问题马上来了。最常见的幼稚写法是：

while (1) { pthread_mutex_lock(&mtx); if (data_ready) break; pthread_mutex_unlock(&mtx); usleep(1000); }

看着能用，实际上每个等待线程都在定时醒来抢锁、检查标志、再睡回去。单线程还好，两三个消费者一起跑，互斥锁会频繁被争抢，CPU 占用率莫名其妙就上去了。更麻烦的是usleep的粒度很难选：睡短了浪费 CPU，睡长了数据到了也得不到及时处理。生产环境里延迟突然抖一下，多半就是这类轮询逻辑在作怪。

轮询还有一个隐藏问题：它把“等待”和“业务条件”耦合到了一起。你为了减少空转，可能不得不在业务代码里夹带各种睡眠和重试逻辑，状态越滚越多，最后没有人敢动这段代码。真正需要的是一种“我只在条件满足时醒来”的原语，睡着的时候不占 CPU，条件变了能立刻收到通知——这就是条件变量和信号量存在的意义。

1.2 条件变量与 POSIX 信号量的定位差异

条件变量和信号量都能用来做同步，但底层思路完全不同。

条件变量本身没有“记忆”。它只负责让线程阻塞，以及被唤醒；真正判断“有没有事可做”的，是线程自己维护的一个谓词条件。所以条件变量必须搭配一个互斥锁使用：锁用来保护谓词和共享数据，pthread_cond_wait负责把“释放锁”和“睡觉”这两个动作做成原子操作。你可以把它理解成一个门铃，按门铃自己不携带任何业务数据，听到门铃后你得自己去看门口是谁。

信号量则自带一个计数器。sem_post会把计数加一，sem_wait会把计数减一，减到负数就阻塞。这个计数器天然记录了“曾经发出过多少次通知”，哪怕你sem_post的时候还没有线程在等待，通知也不会丢。从这个角度讲，信号量更适合做资源计数，比如连接池还有几个空闲、缓冲区还能放几件。

我打过一个比方：条件变量是前台叫号，喊一声“下一个”，喊的时候没人听，这声就白喊了；信号量是停车场计数牌，车进场时牌子减一，车离场时牌子加一，不管有没有人盯着看，计数不会丢。理解了这句话，后面所有 API 的行为就都顺理成章了。

2. 条件变量深度解析：三条 API 背后的等待机制

2.1 pthread_cond_wait 内部到底做了什么

pthread_cond_wait的签名长这样：

int pthread_cond_wait(pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex);

调用它的时候，内部做了三件事：原子地释放互斥锁、把当前线程放入条件变量的等待队列、阻塞。线程被唤醒后，并不是直接返回，而是先重新拿回互斥锁，拿到锁之后pthread_cond_wait才返回。这一步非常关键，它保证了线程重新醒来检查条件时，共享数据不会被其他线程同时改坏。

为什么要设计成“先释放锁再睡”？假设你还是拿着锁睡觉，生产者想修改数据就必须先抢到锁，可锁在你手里，生产者永远抢不到，这就成了死锁。所以条件变量和互斥锁是绑定出现的，wait内部自动释放锁，被唤醒后又自动重新拿锁，整套流程对调用方透明。

理解了这一步，才能看懂为什么“先检查条件再 sleep”的轮询方案需要消灭。在pthread_cond_wait里，检查谓词、释放锁、进入睡眠是一个不可分割的原子序列。如果不用条件变量，你在“发现条件不满足”和“真正去睡”之间总会留一个窗口，另一个线程完全可能在这个窗口里把条件改成满足，而你已经准备睡觉了，于是白白错过一次唤醒。

2.2 等待条件为什么必须写成 while 而不是 if

这是条件变量最容易被忽略、却又最容易出 bug 的细节。网上很多示例代码会写成：

pthread_mutex_lock(&mtx); if (data_ready == 0) { pthread_cond_wait(&cond, &mtx); } // 直接消费 data pthread_mutex_unlock(&mtx);

这份代码在单生产者单消费者、且没有其他线程碰条件时，也许能跑。但只要你把场景稍微扩大一点，它就会随机出问题。POSIX 标准明确允许条件变量产生“虚假唤醒”，哪怕没有人调用signal和broadcast，wait也可能返回。另外，多个消费者同时被broadcast唤醒时，它们会一个个抢到锁，第一个消费者可能已经把数据消费完了，后面醒来的线程拿锁后，数据已经没了。

正确的姿势一定是while：

pthread_mutex_lock(&mtx); while (data_ready == 0) { pthread_cond_wait(&cond, &mtx); } // 到这里才能安全消费 data pthread_mutex_unlock(&mtx);

while让线程醒过来之后重新检查一次条件，如果不满足就继续睡。这等于把“被唤醒”和“条件真的成立”解耦了。我见过不止一个线上事故，最终定位到根因就是这里用了if——压测线程少的时候没暴露，一旦上了多消费者，隔三差五就消费到空数据或者越界。

2.3 可复用的条件变量等待模板

下面这个模板是我实际项目里一直在用的最小骨架，适合单生产者单消费者，也适合多消费者场景。

#include <pthread.h> #include <stdio.h> #include <unistd.h> static pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER; static pthread_cond_t cond = PTHREAD_COND_INITIALIZER; static int data_ready = 0; static void *producer(void *arg) { sleep(1); pthread_mutex_lock(&mtx); data_ready = 1; pthread_mutex_unlock(&mtx); pthread_cond_signal(&cond); return NULL; } static void *consumer(void *arg) { pthread_mutex_lock(&mtx); while (data_ready == 0) { pthread_cond_wait(&cond, &mtx); } printf("got data\n"); pthread_mutex_unlock(&mtx); return NULL; } int main(void) { pthread_t p, c; pthread_create(&c, NULL, consumer, NULL); pthread_create(&p, NULL, producer, NULL); pthread_join(p, NULL); pthread_join(c, NULL); return 0; }

这段代码的关键顺序是：先改共享数据，再释放锁，最后发信号。如果把signal放在unlock之前，虽然大多数情况下也能跑，但会增加无谓的上下文切换，因为signal触发后等待线程会被唤醒，却还要等锁释放才能继续。顺序比较稳妥的是unlock之后再signal。

还有一点必须强调：裸用一个整型标志做谓词，在复杂系统里不够用。生产环境架子一般会定义一个包含锁、条件变量、队列容器和数量字段的结构体，谓词读的是结构体里的count、shutdown等字段。模板的价值在于把“while 检查、wait 循环、signal 通知”这个节奏固定住，后面套任何业务都只是换谓词而已。

3. POSIX 信号量实战：从计数语义到生产者消费者

3.1 sem_t 的计数语义与初始化要点

POSIX 信号量最常用的四个函数是sem_init、sem_wait、sem_post、sem_destroy。还有一个sem_open系列，用于创建具名信号量，可以让不相关的进程共享同一个信号量。线程同步场景下，绝大多数用sem_init就够。

#include <semaphore.h> sem_t sem; sem_init(&sem, 0, 3); // 初始计数为 3 sem_wait(&sem); // 计数减一，计数为 0 则阻塞 sem_post(&sem); // 计数加一，并唤醒一个等待者 sem_destroy(&sem);

第二个参数pshared填 0 表示线程间共享；如果填非 0，表示信号量位于共享内存中、可用于进程间同步。很多人直接填 0 都知道，但不知道填非 0 在 Linux 上是否支持取决于内核配置，所以我写项目时只在本机明确测试通过才敢用进程间模式。最简单可靠的跨进程方案是用sem_open加一个文件路径名字，配合sem_unlink清理。

信号量不允许被复制。sem_t内部有内核状态，你如果写sem_t a = b;，两个对象会操作同一块底层计数，最终行为完全不可控。所以结构体里保存的应该是sem_t的地址，或者直接把sem_t作为结构体字段，但绝不要按值拷贝。

3.2 用两个信号量实现有界缓冲区

信号量解决生产者消费者问题非常经典，思路是把“剩余空位”和“已有数据”分别看成一个资源池。缓冲区容量为 N，则empty初始化为 N，full初始化为 0：

#include <pthread.h> #include <semaphore.h> #include <stdio.h> #include <unistd.h> #define N 4 static int buf[N]; static int in = 0, out = 0; static sem_t empty, full; static pthread_mutex_t io_mtx = PTHREAD_MUTEX_INITIALIZER; static void *producer(void *arg) { int item = 0; while (1) { sem_wait(&empty); buf[in] = item++; in = (in + 1) % N; sem_post(&full); usleep(100000); } return NULL; } static void *consumer(void *arg) { while (1) { sem_wait(&full); int v = buf[out]; out = (out + 1) % N; sem_post(&empty); printf("consume %d\n", v); usleep(200000); } return NULL; }

注意这段代码我故意没加io_mtx的加锁，因为只有一个生产者和一个消费者时，in和out各自只有一个线程在写，环形队列的操作是安全的。但只要生产者有多个，就必须用互斥锁把写buf[in]的临界区包起来；消费者同理。信号量只负责“有没有空位”和“有没有数据”，不负责保护缓冲区本身的并发写。

和条件变量对比一下就能看出差异：条件变量做有界队列要写两个等待循环，一个等not_empty，一个等not_full；信号量直接用empty/full两个计数就把等待逻辑吸收了。资源计数的场景，信号量确实更省事。

4. 实战：任务队列的两种同步实现

4.1 同步方案选型：什么时候用条件变量，什么时候用信号量

实际项目中，任务队列是最常见的同步场景：多个生产者线程把任务塞进队列，多个消费者线程从队列里拿任务执行。选择条件变量还是信号量，主要看两个维度：要不要支持优雅退出，以及等待逻辑的复杂程度。

我的经验是：如果队列逻辑比较简单，纯粹就是“扣一个数、加一个数”，信号量方案更短更不容易错；一旦出现多条件状态，比如队列满、队列空、调度策略、优雅关闭同时要考虑，条件变量配合谓词反而更清晰。信号量的计数是隐式状态，状态一多就难以表达“为什么阻塞”。

4.2 条件变量版本：等待、唤醒与优雅退出

下面这个结构可以直接用到项目中。唯一的锁保护队列的head、tail、count和shutdown，两个条件变量分别对应“队列非空”和“队列未满”。

#include <pthread.h> #include <stdlib.h> #include <string.h> #include <stdio.h> typedef struct { void **slots; int cap, head, tail, count; int shutdown; pthread_mutex_t mtx; pthread_cond_t not_empty; pthread_cond_t not_full; } task_queue_t; void queue_init(task_queue_t *q, int cap) { memset(q, 0, sizeof(*q)); q->cap = cap; q->slots = calloc(cap, sizeof(void *)); pthread_mutex_init(&q->mtx, NULL); pthread_cond_init(&q->not_empty, NULL); pthread_cond_init(&q->not_full, NULL); } void queue_push(task_queue_t *q, void *job) { pthread_mutex_lock(&q->mtx); while (q->count == q->cap && !q->shutdown) { pthread_cond_wait(&q->not_full, &q->mtx); } if (q->shutdown) { pthread_mutex_unlock(&q->mtx); return; } q->slots[q->tail] = job; q->tail = (q->tail + 1) % q->cap; q->count++; pthread_cond_signal(&q->not_empty); pthread_mutex_unlock(&q->mtx); } void *queue_pop(task_queue_t *q) { pthread_mutex_lock(&q->mtx); while (q->count == 0 && !q->shutdown) { pthread_cond_wait(&q->not_empty, &q->mtx); } if (q->count == 0) { pthread_mutex_unlock(&q->mtx); return NULL; } void *job = q->slots[q->head]; q->head = (q->head + 1) % q->cap; q->count--; pthread_cond_signal(&q->not_full); pthread_mutex_unlock(&q->mtx); return job; } void queue_shutdown(task_queue_t *q) { pthread_mutex_lock(&q->mtx); q->shutdown = 1; pthread_mutex_unlock(&q->mtx); pthread_cond_broadcast(&q->not_empty); pthread_cond_broadcast(&q->not_full); }

为什么用两个条件变量而不是一个？如果只用一个条件变量，每次入队都要唤醒所有可能等空队列的消费者，也会唤醒等满队列的生产者，后者醒来后发现队列依然满，只能再睡回去。线程多的时候，这种无意义唤醒会放大成惊群。两个条件变量各唤各的，生产者和消费者互不打扰。

为什么shutdown要配合while？压测关闭时，队列可能满也可能空。queue_push里如果只在count == cap时等待，那么 shutdown 后阻塞的生产者可能永远醒不来，所以wait前必须判断!shutdown，而queue_shutdown要broadcast两个条件变量，把所有人都拖起来。醒来的线程看到shutdown，要么直接退出，要么把自己手里的事收尾，最终queue_pop返回 NULL，消费者线程就能干净退出。

4.3 信号量版本：更简洁但有取舍

信号量版本的有界队列代码明显更短：

#include <pthread.h> #include <semaphore.h> #include <stdlib.h> typedef struct { void **slots; int cap, head, tail; sem_t empty, full; pthread_mutex_t mtx; } sem_queue_t; void sem_queue_init(sem_queue_t *q, int cap) { q->cap = cap; q->head = q->tail = 0; q->slots = calloc(cap, sizeof(void *)); sem_init(&q->empty, 0, cap); sem_init(&q->full, 0, 0); pthread_mutex_init(&q->mtx, NULL); } int sem_queue_push(sem_queue_t *q, void *job) { if (sem_wait(&q->empty) != 0) return -1; pthread_mutex_lock(&q->mtx); q->slots[q->tail] = job; q->tail = (q->tail + 1) % q->cap; pthread_mutex_unlock(&q->mtx); sem_post(&q->full); return 0; } void *sem_queue_pop(sem_queue_t *q) { if (sem_wait(&q->full) != 0) return NULL; pthread_mutex_lock(&q->mtx); void *job = q->slots[q->head]; q->head = (q->head + 1) % q->cap; pthread_mutex_unlock(&q->mtx); sem_post(&q->empty); return job; }

这份代码在“入队出队”这个核心路径上，已经不需要担心虚假唤醒，因为sem_wait每次返回都代表信号量计数确实减一了。但它的短板也很明显：优雅退出很难做。你不能像条件变量那样直接broadcast把所有人都叫醒。常见做法是关闭时往队列里塞 N 个“毒丸”，每个消费者拿到NULL就退出，生产者也通过一个共享标志停止投递。N 个消费者就要塞 N 个毒丸，一旦消费者数量动态变化，这个方案就会变得很难维护。

所以信号量版本适合“启动后不关闭”或者“关闭时直接退出进程”的服务，条件变量版本适合生命周期复杂、需要在线优雅重启的服务。

5. 高频踩坑与排查实录

5.1 丢失唤醒：最隐蔽的竞态

条件变量没有记忆，这条特性会引出一个非常隐蔽的 bug：如果生产者在消费者进入wait之前就调用了signal，而这个通知又没有用谓词记住，消费者之后进入wait，就会一直睡着。

可靠的做法是永远让谓词受同一把互斥锁保护。生产者的正确顺序是：加锁、修改谓词、解锁、发信号；消费者的正确顺序是：加锁、while 检查谓词、wait 或消费、解锁。这样一来，要么消费者先加锁看到谓词已经满足，根本不会睡；要么消费者先进入wait，这时锁已经释放，生产者才能改谓词并发信号。两条路径都不会丢。

我见过最糟糕的写法是生产者先signal再修改数据，或者用一把锁保护数据、却用另一把锁保护谓词。这种代码在低负载时几乎必现丢失唤醒，压测一上去就挂。排查时不要只盯 API 调没调，要检查所有访问谓词的地方是不是同一把锁。

5.2 虚假唤醒与广播惊群

POSIX 标准里明确写了pthread_cond_wait可能产生虚假唤醒，即使没有线程调用signal或broadcast。原因和底层实现有关，但你不必深究，只要所有等待都写成while，虚假唤醒就会变成一次普通的重查，最多多一次上下文切换。

广播惊群是另一类现象。你用了pthread_cond_broadcast，把 10 个消费者全部唤醒，但它们只能一个个抢到锁。抢到锁的第一个消费者把任务取走，剩下 9 个重新进入while，发现队列又空了，继续睡。短期看只是多几次 syscall，如果队列容量很大、消费者很多，每次入队都广播，系统会出现明显的 futex 唤醒风暴。优化方向有两个：能用signal就用signal，因为它只唤醒一个等待者；必须广播时，把批量任务一次推入队列再广播一次，别每个任务广播一次。

5.3 信号量的初始化、EINTR 与销毁

信号量的坑更多集中在边界情况。第一个是sem_destroy忘调。sem_init创建的信号量在某些平台会分配内核资源，不销毁会泄漏。第二个是sem_wait被信号打断。慢系统调用被信号打断时返回 -1 并置errno = EINTR，如果你的代码直接return -1，一个业务线程可能因为一次偶然的信号就退出了。稳妥写法是：

while (sem_wait(&sem) != 0 && errno == EINTR) { /* 继续等 */ }

第三个坑是把sem_t放进结构体后用memset把整个结构体清零。sem_t不是普通整数，清零后再sem_post完全不可预期。结构体初始化时要逐个字段来，信号量必须用sem_init单独初始化，千万别图省事对含sem_t的结构体做memset。

5.4 排查工具和个人方法总结

同步 bug 的特征是“偶尔复现”，排查看代码看不出名堂时，我会直接上工具。先跑strace -f -e futex ./程序，看线程卡在哪个 futex 调用上，能快速确认是不是所有线程都睡在某一个条件变量上。然后再用valgrind --tool=helgrind检查数据竞争，它会把“同一把锁没保护同一块数据”这类问题直接指出来。

以上这些规则看着琐碎，但每一条都是我实际跑挂了之后才咬牙记住的。条件变量和信号量说到底是“让线程等得优雅”的机制，用熟的标志不是背得住 API，而是能在写代码时下意识地问自己：这个线程醒过来之后，真的能保证条件成立吗？带着这个问题写同步代码，至少能避开九成的新手坑。