在前面的学习中，我们掌握了互斥锁和读写锁，它们主要解决线程间的资源竞争问题，保证临界区的独占或共享访问。但在实际开发中，我们常会遇到这样的场景：线程需要等待某个“条件满足”后才能执行（比如消费者等待缓冲区有数据、生产者等待缓冲区有空位），此时仅用锁无法高效实现——若线程循环加锁检查条件，会造成CPU资源的浪费（忙等待）。而条件变量（Condition Variable）正是为解决这一问题而生，它与互斥锁配合使用，构成“等待-通知”模型，让线程在条件不满足时主动阻塞，条件满足时被唤醒，高效实现线程间的协同同步。
一、条件变量的核心概念
条件变量本身不是锁，而是一种线程间的“通知机制”，核心作用是：让线程在某个条件不满足时，主动放弃CPU并阻塞等待，直到其他线程修改条件并发出通知，再唤醒该线程继续执行。
条件变量的核心设计初衷的是避免“忙等待”：如果没有条件变量，线程只能通过“循环加锁→检查条件→解锁”的方式等待条件满足，这会持续占用CPU资源；而条件变量能让线程在条件不满足时进入阻塞状态，释放CPU，直到被唤醒，极大提升了系统资源利用率。
条件变量的使用有一个核心前提：必须与互斥锁配合使用。原因很简单：条件的判断和修改依赖共享资源（比如缓冲区的空满状态），互斥锁用于保护这些共享资源，确保条件检查与修改的原子性，避免出现竞态条件；同时，条件变量的等待和唤醒操作，也需要与互斥锁的加锁、解锁配合，才能保证同步逻辑的安全性。
简单总结：互斥锁解决“资源独占”问题，条件变量解决“线程有序等待”问题，二者协同工作，实现高效、安全的线程同步。
二、条件变量与互斥锁、读写锁的区别
为了更清晰地定位条件变量的作用，我们对比它与之前学习的互斥锁、读写锁的核心差异，明确各自的适用场景：
特性 | 互斥锁（mutex） | 读写锁（rwlock） | 条件变量（cond） |
|---|---|---|---|
核心作用 | 保证临界区独占访问，解决资源竞争 | 区分读写操作，实现读共享、写独占，提升并发效率 | 实现线程间“等待-通知”，避免忙等待，实现线程协同 |
本质 | 独占锁 | 共享-独占锁 | 通知机制（非锁） |
是否依赖其他锁 | 独立使用 | 独立使用 | 必须与互斥锁配合使用 |
适用场景 | 读少写多、读写频率相近 | 读多写少 | 线程需等待某个条件满足（如生产者-消费者模型） |
三、条件变量的常用API（Linux系统）
Linux中条件变量的相关操作均定义在<pthread.h>头文件中，核心API分为4类：初始化、等待、通知、销毁。条件变量的变量类型为pthread_cond_t，且所有API的返回值均为：成功返回0，失败返回非0错误码。
1. 初始化条件变量
条件变量有两种初始化方式：静态初始化和动态初始化，可根据变量的定义位置（全局/局部）选择合适的方式。
// 1. 静态初始化（推荐，适用于全局或静态变量） // 无需手动销毁，系统自动回收资源 pthread_cond_t cond = PTHREAD_COND_INITIALIZER; // 2. 动态初始化（适用于局部变量或动态分配的变量） // 需要手动销毁，避免资源泄漏 int pthread_cond_init(pthread_cond_t *restrict cond, const pthread_condattr_t *restrict attr);参数说明：
cond：指向条件变量的指针，用于操作当前条件变量；
attr：条件变量的属性，通常设为NULL（使用默认属性），一般开发中无需自定义属性；
注意：动态初始化的条件变量，必须在使用完成后手动销毁，否则会造成资源泄漏。
2. 等待条件满足（核心API）
等待条件变量的API有两个版本：普通阻塞版本和带超时的阻塞版本，核心功能是让当前线程在条件不满足时阻塞，释放CPU资源。
// 1. 普通阻塞版本：等待条件满足，直到被唤醒 int pthread_cond_wait(pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex); // 2. 带超时版本：等待指定时间，若仍未被唤醒则返回错误 int pthread_cond_timedwait(pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex, const struct timespec *restrict abstime);核心说明（重点中的重点）：
调用pthread_cond_wait前，当前线程必须已经持有互斥锁（即已调用pthread_mutex_lock）；
函数执行时，会自动完成两个原子操作：① 释放互斥锁；② 让当前线程阻塞在条件变量上。这两个操作是原子的，避免了“线程释放锁后、阻塞前”被其他线程修改条件的竞态问题；
当线程被唤醒（通过pthread_cond_signal或pthread_cond_broadcast）后，会自动重新获取互斥锁，然后从pthread_cond_wait函数返回，继续执行后续代码；
带超时版本pthread_cond_timedwait的abstime参数是“绝对时间”（如当前时间+3秒），超时后会返回错误码（ETIMEDOUT），避免线程永久阻塞。
3. 通知线程（唤醒等待线程）
当条件满足时，通过以下两个API唤醒等待在条件变量上的线程，分为“唤醒一个”和“唤醒所有”两种场景。
// 1. 唤醒至少一个等待在该条件变量上的线程（随机唤醒一个） int pthread_cond_signal(pthread_cond_t *cond); // 2. 唤醒所有等待在该条件变量上的线程 int pthread_cond_broadcast(pthread_cond_t *cond);使用说明：
调用通知API时，建议在“持有互斥锁、修改条件后”调用，确保条件修改的原子性，避免线程被唤醒后条件又被其他线程修改；
pthread_cond_signal效率更高，适用于“只需要一个线程处理条件”的场景（如单一消费者）；
pthread_cond_broadcast适用于“多个线程需要响应条件”的场景（如多个消费者等待数据），避免线程饥饿。
4. 销毁条件变量
仅动态初始化的条件变量需要手动销毁，静态初始化的条件变量无需销毁（系统会自动回收）。销毁前，必须确保所有等待该条件变量的线程都已被唤醒并退出，否则会返回错误（EBUSY）。
int pthread_cond_destroy(pthread_cond_t *cond);注意：销毁条件变量后，不可再对其进行任何操作（如等待、通知），否则会导致未定义行为（如程序崩溃）。
四、条件变量的核心使用模板（必背）
条件变量的使用有固定模板，分为“等待线程”和“通知线程”两部分，核心是“互斥锁保护条件、循环检查条件、通知后唤醒”，具体模板如下：
1. 等待线程（需等待条件满足才能执行）
// 1. 加互斥锁，保护条件变量和共享资源 pthread_mutex_lock(&mutex); // 2. 循环检查条件（重点：用while，而非if） // 原因：避免“虚假唤醒”——即使没有线程通知，等待线程也可能被唤醒 while (条件不满足) { // 3. 条件不满足，阻塞等待，自动释放互斥锁 pthread_cond_wait(&cond, &mutex); } // 4. 条件满足，执行临界区操作（访问共享资源） // ... 业务逻辑 ... // 5. 解锁互斥锁 pthread_mutex_unlock(&mutex);2. 通知线程（修改条件后，唤醒等待线程）
// 1. 加互斥锁，保护条件变量和共享资源 pthread_mutex_lock(&mutex); // 2. 修改条件（关键：必须在互斥锁保护下修改） 条件 = 满足状态; // 3. 唤醒等待线程（根据场景选择signal或broadcast） pthread_cond_signal(&cond); // 唤醒一个线程 // pthread_cond_broadcast(&cond); // 唤醒所有线程 // 4. 解锁互斥锁（建议在通知后解锁，避免线程唤醒后立即阻塞） pthread_mutex_unlock(&mutex);五、实战案例：用条件变量实现生产者-消费者模型
生产者-消费者模型是条件变量最典型的应用场景：生产者线程生产数据放入缓冲区，消费者线程从缓冲区取出数据消费；当缓冲区满时，生产者阻塞等待；当缓冲区空时，消费者阻塞等待。我们用条件变量+互斥锁实现该模型，直观理解条件变量的使用流程。
案例代码
#include <pthread.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> // 定义缓冲区大小 #define BUFFER_SIZE 5 // 缓冲区（存储生产的整数数据） int buffer[BUFFER_SIZE]; // 缓冲区计数（当前数据个数） int count = 0; // 互斥锁：保护缓冲区和count变量 pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; // 条件变量1：缓冲区不满（生产者等待） pthread_cond_t cond_not_full = PTHREAD_COND_INITIALIZER; // 条件变量2：缓冲区非空（消费者等待） pthread_cond_t cond_not_empty = PTHREAD_COND_INITIALIZER; // 生产者线程函数：生产数据，放入缓冲区 void *producer(void *arg) { int tid = *(int *)arg; for (int i = 0; i < 10; i++) { // 生产10个数据 // 加互斥锁 pthread_mutex_lock(&mutex); // 循环检查：缓冲区是否满，满则阻塞等待 while (count == BUFFER_SIZE) { printf("生产者%d：缓冲区已满，等待消费者消费...\n", tid); pthread_cond_wait(&cond_not_full, &mutex); } // 生产数据，放入缓冲区 buffer[count++] = i; printf("生产者%d：生产数据%d，当前缓冲区数据个数：%d\n", tid, i, count); // 通知消费者：缓冲区非空，可以消费 pthread_cond_signal(&cond_not_empty); // 解锁互斥锁 pthread_mutex_unlock(&mutex); // 模拟生产耗时（1秒） sleep(1); } return NULL; } // 消费者线程函数：从缓冲区取出数据，消费 void *consumer(void *arg) { int tid = *(int *)arg; while (1) { // 循环消费 // 加互斥锁 pthread_mutex_lock(&mutex); // 循环检查：缓冲区是否空，空则阻塞等待 while (count == 0) { printf("消费者%d：缓冲区为空，等待生产者生产...\n", tid); pthread_cond_wait(&cond_not_empty, &mutex); } // 消费数据，从缓冲区取出 int data = buffer[--count]; printf("消费者%d：消费数据%d，当前缓冲区数据个数：%d\n", tid, data, count); // 通知生产者：缓冲区不满，可以生产 pthread_cond_signal(&cond_not_full); // 解锁互斥锁 pthread_mutex_unlock(&mutex); // 模拟消费耗时（1秒） sleep(1); } return NULL; } int main() { pthread_t prod_tid, cons_tid; int prod_id = 1, cons_id = 1; // 创建生产者线程和消费者线程 pthread_create(&prod_tid, NULL, producer, &prod_id); pthread_create(&cons_tid, NULL, consumer, &cons_id); // 等待线程结束（实际中消费者为死循环，需手动终止） pthread_join(prod_tid, NULL); pthread_join(cons_tid, NULL); // 销毁互斥锁和条件变量（静态初始化可省略，但写了更规范） pthread_mutex_destroy(&mutex); pthread_cond_destroy(&cond_not_full); pthread_cond_destroy(&cond_not_empty); return 0; }编译与运行
编译时需链接pthread线程库（Linux下线程库默认不自动链接），命令如下：
gcc cond_demo.c -o cond_demo -lpthread ./cond_demo运行结果分析
从运行结果中，可清晰看到条件变量的“等待-通知”逻辑：
生产者线程先生产数据，当缓冲区满（count=5）时，调用
pthread_cond_wait阻塞，释放互斥锁，让消费者线程执行；消费者线程消费数据后，调用
pthread_cond_signal唤醒生产者，生产者被唤醒后重新获取互斥锁，继续生产；当缓冲区空（count=0）时，消费者线程阻塞，等待生产者生产后唤醒；
整个过程中，互斥锁保护缓冲区和count变量，避免竞态条件；条件变量避免了线程忙等待，提升CPU利用率。
六、条件变量的常见错误与避坑要点
忘记与互斥锁配合使用：调用
pthread_cond_wait前未加互斥锁，或未在互斥锁保护下修改条件，会导致竞态条件（如线程检查条件后，条件被其他线程修改），程序可能出现异常。用if代替while检查条件：这是最常见的错误！由于条件变量存在“虚假唤醒”（即使没有线程通知，等待线程也可能被唤醒），若用if检查条件，线程被虚假唤醒后会直接执行临界区操作，导致逻辑错误；必须用while循环，确保线程被唤醒后，再次检查条件是否真的满足。
解锁顺序不当：若先解锁互斥锁，再调用
pthread_cond_signal，可能导致线程被唤醒后，互斥锁已被其他线程获取，从而立即阻塞，影响程序效率；正确做法是：先修改条件，再调用通知API，最后解锁互斥锁。销毁正在被使用的条件变量：若还有线程在等待该条件变量，就调用
pthread_cond_destroy，会返回错误（EBUSY），甚至导致程序崩溃；销毁前必须确保所有等待线程都已退出。滥用pthread_cond_broadcast：盲目使用
pthread_cond_broadcast唤醒所有线程，会导致多个线程同时竞争互斥锁，产生“惊群效应”，浪费CPU资源；仅在需要多个线程响应条件时使用，否则优先用pthread_cond_signal。忽略超时机制：在实际开发中，若仅用
pthread_cond_wait阻塞等待，可能因通知丢失导致线程永久阻塞；关键场景下，建议使用pthread_cond_timedwait设置超时时间，避免线程“卡死”。
七、总结
条件变量是Linux线程同步中核心的“等待-通知”机制，它本身不具备互斥能力，必须与互斥锁配合使用，核心作用是避免线程忙等待，提升系统资源利用率，适用于“线程需等待某个条件满足”的场景（如生产者-消费者、线程池任务调度等）。
核心要点回顾：
条件变量的核心是“等待-通知”，解决线程有序协同问题，依赖互斥锁保护条件和共享资源；
核心API：初始化（init/静态初始化）、等待（wait/timedwait）、通知（signal/broadcast）、销毁（destroy）；
使用模板：等待线程“加锁→循环检查条件→等待→执行→解锁”，通知线程“加锁→修改条件→通知→解锁”；
避坑重点：用while检查条件、与互斥锁配合、正确的解锁顺序、避免滥用broadcast。
至此，我们已经掌握了Linux线程同步的三种核心机制：互斥锁、读写锁、条件变量。下一节，我们将学习线程同步的其他补充机制，以及实际开发中的同步场景选型技巧。
