1 基本概念
1.1 定义与作用
条件变量是并发编程中用于线程协作的一种同步原语，主要功能是让线程在“某个条件尚未满足”时挂起等待，并在条件变化后被唤醒继续执行。它通常不单独使用，而是与互斥锁配套出现，用来协调多个线程对共享状态的访问顺序。
从作用上看，条件变量更关注“什么时候继续做”，而不是“如何保护数据”。因此，它常被用于资源不足、任务未到达、状态未完成等场景，使程序能够避免反复轮询，提升效率与结构清晰度。
1.2 条件变量与互斥锁的关系
条件变量与互斥锁是互补关系。互斥锁负责保护共享数据，保证同一时刻只有一个线程能修改或读取关键状态；条件变量则负责在线程发现条件不成立时进入等待，并在其他线程更新状态后重新检查。
通常的使用方式是：线程先加锁，检查条件；如果条件不满足，就在持锁状态下进入等待。等待过程会暂时释放锁，以便其他线程能够进入临界区修改状态。被唤醒后，线程会重新获得锁，再次判断条件是否已经成立。
1.3 条件变量的核心特征
1.3.1 事件通知机制
条件变量本质上提供了一种事件通知方式。一个线程可以把某个状态变化视为“事件发生”，并通过通知操作提醒等待该事件的线程继续执行。这种机制使线程之间不必通过频繁查询来探测状态，而是以更直接的协作方式完成同步。
1.3.2 条件判断与同步等待
条件变量并不自动代表某种具体条件是否成立，真正的判断逻辑仍由程序员定义，通常体现在共享变量、标志位或队列状态上。线程在等待前必须先检查这些条件，只有确认不满足时才进入阻塞等待；唤醒后也要再次检查，以确保后续操作的正确性。
1.3.3 虚假唤醒与重新检查
条件变量的等待并不保证每次唤醒都对应明确的条件满足，这种现象称为虚假唤醒。为了避免误判，线程不能在被唤醒后直接继续执行，而应重新读取共享状态并再次验证条件。正因如此，条件变量的经典写法通常采用循环判断而不是单次判断。
1.4 条件变量的典型使用场景
条件变量常见于生产者-消费者模型、任务队列、线程池、事件分发、资源池管理等场景。例如，当队列为空时，消费者可以等待；当生产者放入新任务后，再发出通知。又如，在某些阶段性流程中，线程会等待前置步骤完成，再进入下一阶段，从而形成有序协作。
2 工作原理
2.1 等待机制
2.1.1 进入阻塞前的条件检查
线程在调用等待操作之前，通常会先在锁保护下查看共享状态是否满足继续执行的条件。这一步很关键，因为条件变量并不保存“条件是否成立”的信息，它只负责线程的挂起与唤醒。若条件已经成立，就没有必要进入等待。
2.1.2 原子释放锁并等待
当条件不满足时，线程会以原子方式释放互斥锁并进入阻塞状态。所谓原子性，是指“释放锁”和“开始等待”之间不会被其他线程插入打断，从而避免在检查条件与真正睡眠之间错过通知。这一设计是条件变量可靠工作的核心。
2.1.3 被唤醒后的重新加锁
线程收到通知后，并不会立刻执行临界区逻辑，而是先重新获取互斥锁。只有在恢复对共享状态的独占访问后，线程才能再次检查条件并继续后续动作。这样可以保证状态读取与修改仍然处于受控范围内。
2.2 通知机制
2.2.1 单播唤醒
单播唤醒是指通知某一个等待线程继续运行。适合只有一个线程能够真正处理当前条件的场景，例如只有一个任务、一个空闲资源或一个可用名额时。它的优点是开销较小，能够减少无谓竞争。
2.2.2 广播唤醒
广播唤醒会通知所有等待线程重新尝试获取锁并检查条件。它适用于多个线程都可能对同一状态变化做出响应的场景，例如配置更新、阶段切换或多个等待者都可能完成不同工作的情况。不过，广播通常会带来更多调度与竞争成本。
2.2.3 通知时机的选择
通知可以发生在状态更新之后，也可以在某些实现策略下与状态修改紧密配合。一般而言，更重要的是保证“条件已被可靠更新”这一事实被等待线程看到。若通知过早，线程可能醒来后仍发现条件不成立，从而造成额外开销甚至逻辑错误。
2.3 状态变化与协作流程
2.3.1 共享状态更新
条件变量本身不承载业务状态，真正驱动线程协作的是共享变量的变化，如计数器、标志位、队列长度或阶段编号。线程之间通过这些状态来判断是否该等待、是否能继续，以及是否需要通知其他线程。
2.3.2 条件满足后的信号发送
当某个线程完成了状态更新，并使条件变为满足状态时，通常会主动发送信号，提醒等待者重新检查条件。这个过程体现了“一个线程改变环境，另一个线程根据新环境继续执行”的协作关系。
2.3.3 多线程竞争与调度
在多线程环境中，唤醒并不意味着线程会立即执行。被通知的线程还要与其他就绪线程竞争 CPU 和锁资源，实际运行顺序由调度器决定。因此，条件变量提供的是同步机会，而不是执行次序的绝对保证。
3 编程模型
3.1 经典使用模式
3.1.1 while 循环检查条件
条件变量最常见的写法是“锁住、检查、等待、再检查”的循环结构。使用 while 而不是 if，是为了应对虚假唤醒、并发抢占以及多个线程同时被唤醒后的条件失效问题。这种模式几乎是条件变量编程的基本范式。
3.1.2 wait 与 notify 的配合
wait 通常表示当前线程在条件不满足时进入等待，而 notify 或同类操作则表示某个线程已经改变状态，准备唤醒等待者。二者配合时，关键不在于调用顺序本身，而在于共享状态是否已经同步更新，以及等待线程是否会在醒来后重新判断。
3.1.3 锁保护下的状态读写
条件变量依赖共享状态的正确可见性，因此读写这些状态通常都需要在互斥锁保护下进行。这样可以避免一个线程正在判断条件时，另一个线程同时修改状态导致判断失真。锁不仅保护数据，也保护条件判断的时序一致性。
3.2 生产者-消费者模型
3.2.1 缓冲区为空时等待
在生产者-消费者模型中，消费者如果发现缓冲区为空，便会等待条件变量通知。这样可以避免消费者不断轮询队列是否有新内容，减少 CPU 空转，并使线程在真正有工作时再被唤醒。
3.2.2 缓冲区满时等待
当缓冲区达到容量上限时，生产者同样需要等待，直到消费者取走部分数据后再继续写入。条件变量在这里帮助生产者感知“空间已可用”，从而实现对缓冲区容量的协调控制。
3.2.3 生产与消费之间的唤醒关系
生产者和消费者之间通常形成双向唤醒关系：生产者放入数据后唤醒消费者，消费者取走数据后唤醒生产者。通过这种方式，系统可以在“有数据可消费”和“有空间可生产”之间平稳切换，避免资源浪费。
3.3 事件与任务同步
3.3.1 任务完成通知
在任务异步执行场景中，一个线程完成工作后，可以借助条件变量通知等待结果的线程。等待者不需要反复查询任务状态，只需在条件未满足时阻塞，等完成信号到达后再继续处理后续逻辑。
3.3.2 线程协作启动
条件变量也常用于控制多个线程的统一启动。例如，若某些线程需要等待初始化完成、配置就绪或前置资源加载结束，就可以先进入等待状态，直到主线程发出启动通知后再同时展开工作。
3.3.3 状态门控与阶段推进
在分阶段流程中，条件变量可以作为“门控”机制，限制线程只能在指定阶段执行。某一阶段结束后，状态更新与通知操作会推动流程进入下一步，使线程协作更接近流水线式推进。
4 实现与接口
4.1 语言层面的条件变量
4.1.1 C/C++ 中的条件变量
C 和 C++ 体系中常见的条件变量通常与互斥锁搭配使用，接口设计强调在锁保护下等待与通知。其典型特征是等待操作会释放锁并在唤醒后重新获取，从而保证共享状态检查的完整性。
4.1.2 Java 中的等待与通知
Java 中的对象监视器机制也常被用于实现类似条件变量的行为，线程可以在同步块内等待并由其他线程唤醒。除此之外，Java 的并发包还提供了更明确的条件对象，使等待条件的表达更清晰，适合复杂协作场景。
4.1.3 Python 中的条件对象
Python 语言中的条件对象一般与锁共同使用，常用于线程间协调。其接口风格较为直观，通常支持等待、单个通知以及广播通知等操作，适合用于任务队列、生产者-消费者和阶段同步等模式。
4.2 API 常见操作
4.2.1 等待操作
等待操作表示线程在条件不满足时挂起，直到接收到通知或发生其他唤醒事件。多数实现都要求线程在调用等待前持有互斥锁，等待期间则自动释放锁，以便其他线程修改共享状态。
4.2.2 通知单个线程
通知单个线程的操作用于唤醒一个等待者，适合条件变化只对应一个后续执行者的情况。它能减少不必要的唤醒风暴，但前提是程序能够保证被唤醒的线程确实有机会处理当前状态。
4.2.3 通知所有线程
通知所有线程的操作会唤醒全部等待者，让它们重新争夺锁并检查条件。此类操作适合状态变化会影响多个等待线程的场景，但也更容易造成短时间内的竞争增大，因此需要谨慎使用。
4.3 底层实现思路
4.3.1 操作系统同步原语
条件变量的底层通常依赖操作系统提供的同步原语。运行时会把等待线程挂入某种等待队列，并在通知到来时将其移出阻塞状态，交由调度器决定何时真正运行。
4.3.2 线程调度与唤醒队列
等待队列保存了阻塞中的线程信息，通知操作则负责把线程从队列中唤醒。随后，线程能否立刻执行还取决于调度策略、CPU 资源和锁竞争情况，因此通知只是唤醒请求，不是执行保证。
4.3.3 与信号量的实现差异
条件变量与信号量都可用于线程同步，但侧重点不同。条件变量更依赖共享状态和条件判断，本身不保存可累积的“许可”；信号量则更像计数资源，能够记录可用次数。两者在语义上有明显区别，不能简单互换。
5 设计原则与最佳实践
5.1 避免丢失通知
5.1.1 先检查条件再等待
线程在进入等待前必须先检查条件，否则可能在条件已成立时仍然误入睡眠，造成逻辑停滞。先判断、后等待是防止时序错误的基本要求，也是条件变量代码的标准开头。
5.1.2 持锁通知的必要性
通知通常应在持有相关互斥锁的前提下与状态更新配合完成。这样可以确保等待线程看到的是一致的状态快照，避免出现“已经通知但条件尚未准备好”的窗口期，从而减少丢失通知或误唤醒的风险。
5.1.3 状态与信号分离的风险
如果把“通知”当成唯一信息来源，而忽略共享状态本身，就容易产生脆弱设计。因为通知只是一种触发机制，真正决定线程能否继续的是状态是否已改变。将两者分离过度，往往会让程序更难维护。
5.2 正确处理虚假唤醒
5.2.1 以条件循环替代单次等待
为了应对虚假唤醒，等待逻辑应写在循环中，每次被唤醒后都重新判断条件是否满足。这样即使线程只是“被叫醒看看”，也不会错误地越过门槛继续执行。
5.2.2 多线程环境下的稳健写法
在多个等待者并存时，一个通知可能唤醒多个线程，而这些线程最终只有少数能真正获得资源。因此，代码应当假设被唤醒后条件仍可能不成立，并通过重复检查保证行为稳定。
5.2.3 防止条件误判
条件判断应尽量直接、明确，并与共享状态保持一一对应关系。模糊的判断逻辑或复杂的复合条件，容易因状态更新顺序不同而产生误判。将条件拆解为可验证的标志位或计数器，通常更安全。
5.3 性能与可扩展性
5.3.1 减少无效唤醒
无效唤醒会让线程白白争夺锁、检查条件并再次返回等待，增加调度开销。设计时应尽量只唤醒真正可能继续执行的线程，减少多余的上下文切换。
5.3.2 控制广播范围
广播虽然方便，但并不总是高效。若只有少数线程需要响应，单播往往更合适；若确有多个线程都要感知状态变化，广播才更有意义。合理控制广播范围，有助于提升整体吞吐量。
5.3.3 降低锁竞争
条件变量本身并不能消除锁竞争，只是改善等待方式。若共享状态过于集中，仍会出现频繁争锁的问题。通过缩短临界区、拆分状态或减少共享热点，可以让条件变量发挥更好的效果。
6 常见问题
6.1 死锁与等待阻塞
条件变量使用不当时，线程可能长时间等待而不被唤醒，表现为程序卡住。常见原因包括忘记发送通知、条件判断错误、持锁范围不合理，或多个线程互相等待对方先释放资源。与真正的死锁相比，有些情况更像永久阻塞，但外在表现相近。
6.2 竞态条件与时序问题
条件变量常用于解决时序协作，但如果共享状态的读写没有被正确保护，仍可能出现竞态条件。比如，一个线程刚检查完条件，另一个线程便修改了状态，导致前者进入了错误路径。同步原语本身不能替代严谨的状态管理。
6.3 错误使用 notify 与 notify_all
常见错误包括：在只需唤醒一个线程时广播所有等待者，造成性能浪费；或者本应唤醒多个等待者时只通知一个，导致其他线程持续阻塞。另一个问题是通知顺序与状态更新配合不当，使唤醒发生得过早或过晚。
6.4 条件变量与忙等的比较
忙等是线程不断循环检查条件，即使条件尚未满足也持续占用 CPU。条件变量则允许线程在条件不满足时挂起等待，把处理器资源让给其他任务。相比忙等，条件变量通常更节能、更适合大多数协作型并发场景。
7 相关概念
7.1 互斥锁
互斥锁是一种用于保护共享资源的同步原语，确保同一时刻只有一个线程进入临界区。条件变量通常依附于互斥锁工作，两者共同构成线程同步的基础组合。
7.2 信号量
信号量是一种带计数的同步机制，可用于控制并发访问数量或表示资源许可。与条件变量相比，信号量更强调“可用资源的数量”，而条件变量更强调“状态是否满足”。
7.3 读写锁
读写锁允许多个读线程并发访问，但写线程通常需要独占权限。它适合读多写少的场景，而条件变量则更适合线程之间的等待与通知协作。两者在用途上不同，但有时会在复杂系统中共同出现。
7.4 事件对象
事件对象是一类用于线程通知的同步机制，常见于某些运行时或操作系统环境。它和条件变量有相似之处，都是用于表达“某个事件发生了”，但在具体语义、重置方式和等待模型上可能有所区别。
7.5 屏障与栅栏
屏障与栅栏用于让多个线程在某个阶段汇合，直到所有参与者都到达后再继续执行。它们强调“集体同步点”，与条件变量的“条件满足后继续”在概念上不同，但都属于线程协调工具。