Linux线程同步实战：互斥锁与条件变量实现生产者消费者模型

写多线程程序的时候，最常遇到的是什么？不是语法错误，而是“没跑几步就崩了”“运行十次有一两次结果不对”“加了延时就像好了，一开优化又坏了”。这些问题十有八九出在同一个地方：线程同步没做好。今天这篇就围绕Linux环境下线程同步的核心机制——互斥锁和条件变量——把生产消费模型完整地拆一遍，从原理讲到可运行的代码，再说到多生产者多消费者场景下的坑。适合刚接触Linux C/C++多线程编程、或者写过简单线程但没系统性理解同步机制的同学，也适合要应付面试题里高频考点的人。

1. 从竞态条件说起：为什么生产消费不能“裸奔”

1.1 一次真实的多线程“事故”现场

先看一个我实际遇到过的例子。给一个日志服务加了统计线程，主线程每处理完一条消息就执行 counter++，统计线程每2秒读一次 counter 并清零。上线后打印出来的数字经常比真实值少几千甚至上万。

原因不难猜：counter++ 在CPU层面至少是“读取→加一→写回”三步，两个线程同时对它操作，中间任何一步被打断都会丢更新。更隐蔽的是在多核机器上，即使没有被打断，由于CPU缓存一致性，一个核改完的值另一个核不一定立刻能看到。这不是玄学，是并发编程里最基础的竞态条件。

要解决这种问题，最直接的手段就是互斥锁：同一时刻只允许一个线程进入临界区。

1.2 竞态条件、临界区与原子性

关键概念先理清：

• 临界区：访问共享资源的代码段，比如上面那句 counter++。
• 竞态条件：多个线程同时进入临界区，最终结果取决于线程调度顺序。
• 原子性：一个操作要么完整执行，要么完全不执行，中间不可被打断。

互斥锁本质上就是在临界区外面加一道门，让多个线程排队进入。但要注意，“加锁”这个概念本身有迷惑性：锁不是“锁住数据”，而是“锁住代码路径”。就算你在一个线程里加了锁、另一个线程不遵守约定直接访问共享数据，锁依然挡不住。所以生产消费模型里，所有读写共享队列的代码必须遵循同一套加锁协议。

1.3 生产消费模型到底在解决什么问题

生产消费模型是通过一个共享缓冲区，让生产者和消费者解耦。生产者只管往缓冲区放数据，不关心谁消费、怎么消费；消费者只管从缓冲区取数据，不关心数据从哪来。这个模式解决了三件事：

1. 解耦：生产逻辑和消费逻辑可以独立扩展。
2. 缓冲：生产和消费速度不一致时，缓冲区起到削峰填谷的作用。
3. 异步化：生产者不用等消费者处理完再继续干活，吞吐量立刻上来。

在Linux环境下，最经典的实现组合就是 pthread_mutex_t + pthread_cond_t。下面两章先把这两样东西的原理讲透，再上代码。

2. 互斥锁的底层逻辑与使用细节

2.1 pthread_mutex的基本API

使用互斥锁的整套流程很简单，就四个动作：

c复制pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;  // 静态初始化

pthread_mutex_lock(&mtx);      // 加锁，拿不到就阻塞
// 临界区代码
pthread_mutex_unlock(&mtx);    // 解锁

除了静态初始化，也可以用 pthread_mutex_init(&mtx, NULL) 动态初始化，用完之后要调用 pthread_mutex_destroy(&mtx) 清理。两种方式差别不大，动态初始化可以传入属性对象，比如设置成“进程间共享”或者“递归锁”。

有几个必须养成的习惯：

• 加锁之后务必在每条退出路径上解锁。函数里分支一多，很容易写出“异常分支忘记解锁”的代码。C语言没有 RAII 兜底，只能靠自觉，或者封装成 lock_guard 之类的辅助结构。
• 不要把 lock 和 unlock 放在两个相隔很远的函数里，否则维护成本很高。
• 解锁动作本身很快，但临界区越长，其他线程等待时间越长，所以临界区要尽量短。

2.2 底层实现：从CAS到futex

很多人以为 pthread_mutex_lock 一旦调用就会陷入内核，让出CPU。实际上Linux下的互斥锁是“混合”实现：先尝试在用户态用原子CAS操作抢锁，抢不到才通过 futex（Fast User-space muTEX）系统调用进入睡眠。

没有竞争的时候，加锁只是几条原子指令的事，不涉及系统调用，所以性能非常高。只有在锁被占用时，等待线程才会挂起，由内核在解锁时唤醒。这也是互斥锁和自旋锁（spinlock）的核心区别：

生产消费模型的临界区里通常要做队列读写、甚至打印日志，这些操作都可能耗时，适合用互斥锁而不是自旋锁。而且glibc的互斥锁实现本身就带“先自旋一小会儿再睡眠”的自适应逻辑，临界区极短的时候也不会立刻被踢出CPU。

2.3 锁粒度：越小越好，但不是越小越好

锁粒度是个经典选择题。把整个队列读写包在一把锁里，简单、安全、不容易出错；但临界区长了，并发度就低。反过来，如果为了并发把队列拆成多个桶、每个桶一把锁，处理边界情况时又要面对死锁和一致性问题。

我的建议是：先把逻辑写对，再优化锁粒度。 生产消费模型第一阶段用一把锁保护整个队列就够了。真正要提高吞吐量，先把锁内耗时的操作移出去（比如把打印信息挪到解锁之后），这比拆锁简单有效得多。

2.4 互斥锁类型：不要轻易用递归锁

pthread_mutex 可以通过属性设置为不同类型：

递归锁看起来方便，比如一个函数里先加锁，又调用了另一个也加同一把锁的函数，不会立刻死锁。但大多数情况下这说明函数边界和锁边界没设计好，递归锁只是掩盖问题。我在项目里基本只用默认的普通锁。

3. 条件变量：线程之间怎么“通气”

3.1 只有一个互斥锁会怎样

如果只有互斥锁，生产消费模型也能写，只是很难受。比如缓冲区空的时候，消费者需要不断“尝试加锁→看有没有数据→解锁→再等一会儿→再加锁”，这就是忙等待。忙等白白消耗CPU，而且等待时间越长浪费越严重。

条件变量就是来解决“等待与通知”问题的：消费者发现没数据，就进入睡眠等待；生产者放入数据后，发一个通知把消费者唤醒。这比忙等省电得多，也更符合直觉。

3.2 为什么pthread_cond_wait必须带上互斥锁

条件变量API非常特殊，不能单独使用。标准用法是：

c复制pthread_mutex_lock(&mtx);
while (!has_data) {
    pthread_cond_wait(&cond, &mtx);
}
// 此时条件成立，并且持有锁
pthread_mutex_unlock(&mtx);

pthread_cond_wait 做的事情是一个原子序列：释放mtx → 挂起睡眠等待 → 被唤醒 → 重新获取mtx。

有人会问：为什么不先 unlock(&mtx)，再 wait(&cond)？因为这两步之间存在窗口期。假如消费者先释放锁，还没进入等待状态时，生产者抢到锁放入了数据并调用了 signal，那么这个信号就丢失了，消费者随后进入睡眠，永远等不到数据。把锁传给 cond_wait，让“释放锁”和“进入等待”在同一个原子操作里完成，就不会丢失唤醒。

打个比方：去餐厅吃饭，你得先把座位让出来，同时告诉服务员“我在排队”，服务员有座了才叫你。如果你是先站起来、走出去转了一圈再回来排队，服务员在你走出门的那一刻喊了号，你就错过了。

3.3 虚假唤醒与while循环

这是条件变量最容易踩的坑。pthread_cond_wait 即使在没有任何线程调用 signal / broadcast 的情况下，也可能被调度器唤醒，这叫“虚假唤醒”。再加上多生产者多消费者场景里，就算没有虚假唤醒，也可能存在“信号被其他线程截胡”的情况。

比如有两个消费者都在等数据，生产者 signal 一个线程，按语义应该唤醒其中一个；但A线程被唤醒后还没抢到锁，B线程先抢到锁把数据取走了；等A真正抢到锁时，缓冲区又空了。

所以正确的等待逻辑必须是：

c复制while (!has_data) {
    pthread_cond_wait(&cond, &mtx);
}

绝对不能写成 if。wait 返回后要重新检查谓词条件，不成立就继续等。

3.4 signal与broadcast的区别

• pthread_cond_signal：唤醒一个正在等待该条件的线程。不确定唤醒哪个，但至少一个。
• pthread_cond_broadcast：唤醒所有正在等待该条件的线程。

生产消费模型里大部分场景用 signal 就够。如果唤醒一个消费者，它拿不到数据会自己继续等，没必要把其他消费者都叫起来抢锁。用 broadcast 反而会造成惊群效应：多个线程同时被唤醒，但只有一个能抢到锁，其他线程又得重新睡眠，白白增加上下文切换。

什么时候用 broadcast？比如“所有线程都该退出”的退出信号，或者“缓冲区状态变化巨大，每个线程都需要重新评估”的场景。生产消费模型里很少需要。

3.5 一个条件变量还是两个

实现生产消费模型至少要回答一个问题：消费者等“缓冲区非空”，生产者等“缓冲区非满”。这两个等待条件是不同的。

如果只用一个条件变量，生产和消费都用它，会出现一种低效但能跑的情况：生产者 signal 之后，被唤醒的可能是另一个生产者，而不是消费者；这个生产者发现缓冲区已经满了，只能继续睡。真正的消费者没有被唤醒，直到下一次信号到来。

用两个条件变量就能把等待对象分开：

• cond_not_empty：消费者等数据，生产完信号它。
• cond_not_full：生产者等空位，消费完信号它。

配合 signal 使用，语义非常清晰：生产者一定唤醒消费者，消费者一定唤醒生产者。这是我在代码实践里强烈推荐的做法。

3.6 signal放在unlock前还是后

这是老生常谈的话题。两种写法都能工作，因为 cond_wait 返回时会重新抢锁，signal 只是把线程从等待队列移到就绪队列，并不直接给它锁。

但为了减少不必要的锁竞争，我习惯先 unlock 再 signal：

c复制pthread_mutex_unlock(&mtx);
pthread_cond_signal(&cond);

这样被唤醒的线程从 cond_wait 返回时，锁已经是可用的，不需要再和当前线程抢一次。当然，真实场景里这个优化影响很小，但养成这个习惯可以避免在一些慢速实现上的额外开销。

4. 跑通生产消费模型：代码实战与逐步拆解

4.1 版本一：单缓冲模型

先写一个最简版本。缓冲区只有一个位置，生产者和消费者严格交替。“有数据”这个状态用一个int变量表示。

c复制#include <stdio.h>
#include <pthread.h>
#include <unistd.h>

pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond_not_full = PTHREAD_COND_INITIALIZER;
pthread_cond_t cond_not_empty = PTHREAD_COND_INITIALIZER;

int buffer;
int has_data = 0;   // 0 空，1 满

void* producer(void* arg) {
    int item = 0;
    while (1) {
        item++;
        pthread_mutex_lock(&mtx);

        while (has_data) {
            pthread_cond_wait(&cond_not_full, &mtx);
        }

        buffer = item;
        has_data = 1;
        printf("produce: %d\n", item);

        pthread_cond_signal(&cond_not_empty);
        pthread_mutex_unlock(&mtx);

        usleep(200000);   // 模拟生产耗时
    }
    return NULL;
}

void* consumer(void* arg) {
    while (1) {
        pthread_mutex_lock(&mtx);

        while (!has_data) {
            pthread_cond_wait(&cond_not_empty, &mtx);
        }

        int item = buffer;
        has_data = 0;
        printf("consume: %d\n", item);

        pthread_cond_signal(&cond_not_full);
        pthread_mutex_unlock(&mtx);

        usleep(300000);   // 模拟消费耗时
    }
    return NULL;
}

int main() {
    pthread_t p, c;
    pthread_create(&p, NULL, producer, NULL);
    pthread_create(&c, NULL, consumer, NULL);
    pthread_join(p, NULL);
    pthread_join(c, NULL);
    return 0;
}

这个版本有几个关键点要解释：

• has_data 不只是一个普通变量，它是“谓词条件”，代表缓冲区当前状态。所有读写它的动作都必须在锁内完成。
• 生产者和消费者各用各的条件变量，等待对象完全不同。
• 生产者等 cond_not_full，消费者等 cond_not_empty，signal方向沿着“生产和消费”相反方向发，不会出现生产者唤醒生产者的情况。

单缓冲模型的问题很明显：缓冲区深度只有1，生产和消费被绑成严格交替的节奏，性能低。真实场景里不会用这种模型，但它非常适合理解条件变量的工作流程。

4.2 版本二：环形缓冲队列

把单缓冲改成环形队列，缓冲区可以容纳多个数据，生产和消费才能并行起来。这也是生产消费模型最常见的实现形态。

c复制#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>

#define CAPACITY 8

typedef struct {
    int *data;
    int capacity;
    int head;   // 队首
    int tail;   // 队尾
    int count;  // 当前元素数量
} ring_buffer_t;

ring_buffer_t rb;
pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond_not_full = PTHREAD_COND_INITIALIZER;
pthread_cond_t cond_not_empty = PTHREAD_COND_INITIALIZER;

void rb_init(ring_buffer_t *rb, int capacity) {
    rb->data = (int*)malloc(sizeof(int) * capacity);
    rb->capacity = capacity;
    rb->head = rb->tail = rb->count = 0;
}

int rb_is_empty(ring_buffer_t *rb) {
    return rb->count == 0;
}

int rb_is_full(ring_buffer_t *rb) {
    return rb->count == rb->capacity;
}

void rb_push(ring_buffer_t *rb, int val) {
    rb->data[rb->tail] = val;
    rb->tail = (rb->tail + 1) % rb->capacity;
    rb->count++;
}

int rb_pop(ring_buffer_t *rb) {
    int val = rb->data[rb->head];
    rb->head = (rb->head + 1) % rb->capacity;
    rb->count--;
    return val;
}

void* producer(void* arg) {
    long id = (long)arg;
    int item = 0;
    while (1) {
        item++;

        pthread_mutex_lock(&mtx);
        while (rb_is_full(&rb)) {
            pthread_cond_wait(&cond_not_full, &mtx);
        }

        rb_push(&rb, item);
        printf("[P%ld] produce %d, count=%d\n", id, item, rb.count);

        pthread_cond_signal(&cond_not_empty);
        pthread_mutex_unlock(&mtx);

        usleep(200000);
    }
    return NULL;
}

void* consumer(void* arg) {
    long id = (long)arg;
    while (1) {
        pthread_mutex_lock(&mtx);
        while (rb_is_empty(&rb)) {
            pthread_cond_wait(&cond_not_empty, &mtx);
        }

        int item = rb_pop(&rb);
        printf("[C%ld] consume %d, count=%d\n", id, item, rb.count);

        pthread_cond_signal(&cond_not_full);
        pthread_mutex_unlock(&mtx);

        usleep(300000);
    }
    return NULL;
}

int main() {
    rb_init(&rb, CAPACITY);

    pthread_t t1, t2;
    pthread_create(&t1, NULL, producer, (void*)1);
    pthread_create(&t2, NULL, consumer, (void*)1);

    pthread_join(t1, NULL);
    pthread_join(t2, NULL);

    free(rb.data);
    return 0;
}

环形队列里 count 是核心状态，通过它判断空和满。head 和 tail 的移动都靠取模 % capacity 实现，不会越界。

注意 rb_push 和 rb_pop 本身没有加锁，它们必须在调用者持有 mtx 的情况下执行。这个例子里的队列函数只做数据搬运，把锁的控制权完全交给生产者和消费者线程函数。这种“数据结构和锁分开”的写法的好处是逻辑集中，读代码时一眼能看到所有加锁解锁的边界。

4.3 编译运行与验证

编译命令：

bash复制gcc -pthread -o pc pc.c

注意是 -pthread 而不是 -lpthread。-pthread 会同时定义 _REENTRANT 宏，并正确链接线程库，是我在所有Linux项目里用的标准写法。

运行起来会看到生产者和消费者交替输出。如果想验证是否存在数据竞争，可以用Helgrind或ThreadSanitizer：

bash复制valgrind --tool=helgrind ./pc

或者编译时开启:

bash复制gcc -pthread -fsanitize=thread -g -o pc pc.c

这两个工具能检测出锁使用错误和竞态条件，强烈建议作为多线程程序的常规检查手段。我实际用下来的体会是：ThreadSanitizer更快，报错信息也更友好；Helgrind在某些复杂的锁顺序问题上反而更详细。

5. 多生产者多消费者进阶：死锁、惊群与锁粒度实测

5.1 多生产多消费的代码改动很小

把上面的例子改成3个生产者、2个消费者，只需要多创建几个线程，线程函数几乎不变：

c复制pthread_t producers[3], consumers[2];

for (long i = 0; i < 3; i++) {
    pthread_create(&producers[i], NULL, producer, (void*)i);
}
for (long i = 0; i < 2; i++) {
    pthread_create(&consumers[i], NULL, consumer, (void*)i);
}

for (int i = 0; i < 3; i++) pthread_join(producers[i], NULL);
for (int i = 0; i < 2; i++) pthread_join(consumers[i], NULL);

线程函数里已经有 while 循环重新检查谓词条件，所以多消费者场景下即使被唤醒后发现缓冲区又被别的消费者取空，也会正确回到等待状态，不会访问到空队列。这就是第3章强调 while 而不是 if 的原因之一。

5.2 惊群效应：什么时候该用broadcast

多消费者场景下，生产者生产一条数据，理论上只需唤醒一个消费者。如果这时候用 pthread_cond_broadcast，所有等待中的消费者都会被唤醒，但只有抢到锁的那一个能取到数据，其余人发现队列空了（或者又满了），只能继续睡觉。一次 broadcast 造成多次无效的上下文切换和锁竞争，这就是惊群。

所以要记住一个原则：**一份资源能只满足一个等待者时，用signal；资源状态变化大到需要所有等待者重新评估时，才用broadcast。**生产消费模型里“队列非空”和“队列非满”的信号，都应该用signal。

我不止一次看到有人因为“担心signal可能丢失”而全部写成broadcast，导致压力测试时线程上下文切换数量暴涨。多线程程序的性能，很多时候就死在这种看起来没问题的写法上。

5.3 锁内printf：性能杀手

我最想提醒的一个实践问题是：不要在临界区里做打印操作。

printf 本身是行缓冲的，内部还有自己的锁，线程频繁调用时会产生极大的串行开销。更重要的是，一旦把 printf 放进互斥锁临界区，所有生产者和消费者的执行速度会被打印速度拖住。测试时为了调试方便可以这么写，但压测时必须把 printf 挪到解锁之后，或者干脆换成日志库并在外部异步落盘。

我在一次压测里只做了“把printf移出临界区”这一个改动，吞吐量从每秒几百条直接提升到几万条。很多时候性能瓶颈根本不是锁本身，而是临界区里塞了太多无关操作。

5.4 死锁排查：gdb与pstack

生产消费模型只用一把锁，死锁概率其实不高，但如果项目里混入了其他锁，就要警惕经典的死锁四条件：互斥、持有并等待、不可剥夺、循环等待。

排查死锁最直接的办法是挂住现场，用 gdb 附加到进程，执行 thread apply all bt 查看所有线程的堆栈，看每个线程阻塞在哪个锁上。没有gdb的环境可以用：

bash复制pstack <pid>

它会打印进程内所有线程的调用栈，锁的使用点一目了然。

还有一种比较隐蔽的情况：某个线程在持有锁A的时候调用了 pthread_cond_wait(&cond, &mtx)，cond_wait 会释放mtx，但不会释放其他锁。如果其他线程需要那把额外的锁才能进入 signal 路径，就会形成死锁。这就是为什么我建议生产消费模型里只围绕一把锁展开，不要在等待条件变量时携带其他锁。

5.5 条件变量之外的优化方向

当锁竞争已经成为瓶颈时，有几个方向可以继续深挖：

• 无锁队列：用CAS实现SPSC（单生产者单消费者）环形队列，可能彻底去掉锁。
• 分区加锁：多个队列，每个队列独立锁，降低冲突概率。
• 批量搬运：生产者攒一批数据再入队，减少唤醒次数。

但这些都属于进阶优化，前提是你已经确定条件变量版本能跑通、逻辑正确。我见过太多人一上来就搞无锁队列，最后在ABA、内存序、内存屏障上折腾几周还不如老老实实加锁。并发编程的第一原则永远是：先保证正确，再谈性能。

再补充一个实际经验：如果你用 pthread_cond_timedwait 做超时等待，一定要记得在循环里检查超时返回值。很多程序在超时后把“条件不满足”当成“条件满足”去处理，查半天发现是返回值判断反了。ETIMEDOUT 只是说明等待超时，不代表你要消费的数据已经就绪，代码里要明确区分这两种情况。

生产消费模型是Linux线程同步的基本功，也是面试最常问的知识点之一。真正把它吃透，靠的不是背API，而是亲手把一个演示程序改成多生产者多消费者版本，再上压力测试，看看锁、条件变量、临界区对性能的直接影响。这套流程走一遍，后面看什么并发代码都会轻松很多。