4、线程等待与通知：QWaitCondition的使用、生产者-消费者模型实现、条件变量的正确用法

在多线程编程中，线程之间不仅需要共享数据，更需要一种高效的同步机制来协调执行节奏。互斥锁（QMutex）解决了资源互斥访问的问题，但无法解决线程间的等待与通知问题——例如，当消费者线程发现缓冲区为空时，它应当等待而非忙轮询；当生产者线程放入新数据后，需要及时唤醒等待中的消费者。Qt 提供的 QWaitCondition（条件变量）正是为解决此类问题而设计的核心工具。本章将深入剖析 QWaitCondition 的工作原理、与 QMutex 的协作方式，并通过完整的生产者-消费者模型展示其正确用法，同时总结常见陷阱与性能调优经验。

上图展示了 QWaitCondition 在生产者-消费者模型中的核心地位：生产者与消费者通过共享缓冲区交互，而条件变量负责在缓冲区状态变化时高效地传递信号，避免忙等待带来的 CPU 浪费。下面我们将从原理到实战逐步展开。

4.1 核心原理：条件变量的本质与 QWaitCondition 的 API

条件变量（Condition Variable）是一种高级同步原语，它允许线程在某个条件不满足时主动让出 CPU 进入阻塞状态，并在条件可能满足时被其他线程唤醒。与互斥锁不同，条件变量本身不保护数据，而是与互斥锁配合使用，解决“等待-通知”的语义问题。

QWaitCondition 在 Qt 中提供了跨平台的实现，其关键 API 如下：

理解 wait() 的原子性至关重要：当线程调用 wait(&mutex) 时，操作系统会同时完成两个操作——将当前线程加入等待队列，并释放 mutex。这两个步骤不可分割，从而避免了“释放锁后、进入等待前”的竞态窗口。当线程被唤醒时，wait() 返回前会重新获取 mutex，然后继续执行。

4.2 判断方法与操作流程：正确使用条件变量的五步法

要避免死锁、丢失唤醒、虚假唤醒等经典问题，必须遵循一套严谨的操作流程。以下是经过验证的五步法：

1. 定义共享状态与互斥锁：使用 QMutex 保护所有共享数据（如队列、计数器），条件变量本身不保护数据。
2. 在 wait 前必须持有锁：调用 wait() 前，当前线程必须已经 lock 了同一个 QMutex。
3. 使用 while 循环检查条件：将 wait() 放在 while(条件不满足) 循环内，而非 if 内。这能应对虚假唤醒（spurious wakeup）和多个消费者被同时唤醒但只有一个数据可消费的情况。
4. 修改共享状态后必须通知：在修改完共享数据、释放锁之前（或之后），调用 wakeOne() 或 wakeAll() 通知等待线程。
5. 释放锁：通知后，尽快释放互斥锁，让等待线程有机会获取锁并继续执行。

下面是一个典型的等待端代码模式：

// 消费者等待数据
mutex.lock();
while (buffer.isEmpty()) {
    // 条件不满足，释放锁并阻塞等待
    // 被唤醒后，wait() 返回前会重新获取锁
    condition.wait(&mutex);
}
// 此时条件满足，且持有锁
auto data = buffer.dequeue();
mutex.unlock();

对应的通知端模式：

// 生产者放入数据
mutex.lock();
buffer.enqueue(newData);
// 通知一个等待的消费者
condition.wakeOne();
mutex.unlock();

4.3 案例拆解：基于 QWaitCondition 的生产者-消费者模型

我们构建一个完整的实战案例：一个图像处理流水线，主线程作为生产者生成待处理的图像帧，三个工作线程作为消费者并行处理。缓冲区容量固定为 10 帧，当缓冲区满时生产者必须等待，当缓冲区空时消费者必须等待。

背景与约束：系统需要处理实时视频流，每帧处理耗时约 20ms。若使用忙轮询，CPU 占用率将高达 100%；若使用固定 sleep，则延迟不可控。因此必须使用条件变量实现事件驱动。

初始现象：初版代码使用 QMutex + 轮询检查缓冲区大小，导致 CPU 占用率 85% 以上，且响应延迟波动大。

关键实现：

class Buffer {
public:
    Buffer(int maxSize) : m_maxSize(maxSize) {}
    void produce(int frame) {
        QMutexLocker locker(&m_mutex);
        while (m_queue.size() >= m_maxSize) {
            m_notFull.wait(&m_mutex); // 缓冲区满，等待
        }
        m_queue.enqueue(frame);
        m_notEmpty.wakeOne(); // 通知消费者
    }
    int consume() {
        QMutexLocker locker(&m_mutex);
        while (m_queue.isEmpty()) {
            m_notEmpty.wait(&m_mutex); // 缓冲区空，等待
        }
        int frame = m_queue.dequeue();
        m_notFull.wakeOne(); // 通知生产者
        return frame;
    }
private:
    QMutex m_mutex;
    QWaitCondition m_notFull;
    QWaitCondition m_notEmpty;
    QQueue<int> m_queue;
    int m_maxSize;
};

// 生产者线程
void producer(Buffer *buf) {
    for (int i = 0; i < 100; ++i) {
        buf->produce(i);
        QThread::msleep(5); // 模拟采集间隔
    }
}
// 消费者线程
void consumer(Buffer *buf) {
    while (true) {
        int frame = buf->consume();
        // 处理图像帧...
        QThread::msleep(20); // 模拟处理耗时
    }
}

分析判断过程：我们使用两个独立的 QWaitCondition（m_notFull 和 m_notEmpty）分别管理“缓冲区非满”和“缓冲区非空”两个条件。这比单一条件变量更高效，因为生产者只需唤醒消费者，消费者只需唤醒生产者，避免了无意义的广播。

结果对比：改造后，CPU 占用率降至 3% 以下，且处理延迟稳定在 20ms 左右。更重要的是，当缓冲区满时，生产者线程完全阻塞，不消耗任何 CPU 周期。

风险与代价：条件变量引入了上下文切换开销，但相比忙轮询节省的 CPU 资源，这种开销微不足道。需要注意的是，wakeOne() 不保证唤醒哪个线程，若多个消费者等待，可能造成线程饥饿。在本案例中，由于所有消费者处理能力相同，饥饿问题不明显。

复盘经验：使用两个条件变量比单个条件变量更清晰且高效；QMutexLocker 确保异常安全；while 循环是必须的，因为可能多个生产者同时被唤醒，但缓冲区空间只够一个生产者写入。

4.4 常见误区与总结复盘

即使理解了 API，开发者在实践中仍会陷入以下陷阱：

性能调优建议：

• 优先使用 wakeOne() 而非 wakeAll()，除非所有等待线程都必须被唤醒。
• 考虑使用 wait(&mutex, timeout) 设置超时，防止因逻辑错误导致永久阻塞。
• 对于高频小数据量的场景，可考虑无锁队列（如 QAtomicInt + 环形缓冲），但复杂度显著增加。
• 使用 QThreadPool 和 QtConcurrent 可以简化多线程任务分发，但底层仍是条件变量机制。