📚 课程目录第3章线程同步基础

3、线程同步基础：QMutex、QReadWriteLock、QSemaphore、QWaitCondition的使用与区别

在多线程程序中，线程之间共享数据是常态，但共享必然带来竞争。Qt 提供了四种核心同步原语——QMutex、QReadWriteLock、QSemaphore 和 QWaitCondition，它们分别适用于不同的并发场景。理解它们的本质区别，是设计高效、稳定多线程应用的基础。本章将从原理、适用场景、操作流程和常见误区四个维度展开，并通过一个综合案例演示如何组合使用这些工具。

3.1 核心原理：四种同步原语的本质

QMutex 是最基础的互斥锁，它保证同一时刻只有一个线程可以进入临界区。其内部实现通常基于操作系统提供的 futex 或临界区对象，当锁被占用时，其他尝试加锁的线程会进入休眠状态，直到锁被释放。QMutex 的关键特性是不可重入——同一个线程不能对同一把 QMutex 连续加锁两次，否则会死锁。如果需要可重入行为，应使用 QRecursiveMutex。

QReadWriteLock 是对 QMutex 的优化，它区分读操作和写操作。多个线程可以同时持有读锁，但写锁是独占的。这种设计适用于“读多写少”的场景，例如配置缓存、路由表等。需要注意的是，如果写线程长时间等待，可能会发生“写饥饿”问题，Qt 默认采用写优先策略来缓解。

QSemaphore 是一个计数信号量，它维护一个内部计数器。acquire() 会减少计数（若计数为 0 则阻塞），release() 会增加计数。信号量不绑定特定线程，因此非常适合控制对有限资源池（如数据库连接池、网络连接池）的访问，或者实现生产者-消费者队列。

QWaitCondition 是条件变量，它必须与 QMutex 配合使用。线程在持有锁的情况下调用 wait()，会原子性地释放锁并进入休眠；其他线程调用 wakeOne() 或 wakeAll() 唤醒等待线程。条件变量解决的是“等待某个条件成立”的问题，例如任务队列从空变为非空。

同步原语	核心机制	典型场景	是否可超时	是否可重入
QMutex	独占锁	保护简单临界区	tryLock(ms)	否（QRecursiveMutex 可）
QReadWriteLock	读共享/写独占	读多写少的数据结构	tryLockForRead/Write(ms)	否
QSemaphore	计数信号量	资源池、生产者-消费者	tryAcquire(1, ms)	不适用
QWaitCondition	条件变量	线程间事件通知	wait(ms)	不适用

3.2 判断方法与操作流程：如何选择正确的同步工具

选择同步原语时，可以按照以下决策路径进行判断：

明确共享资源的访问模式：是简单的读写互斥，还是需要控制并发数量？如果是前者，继续下一步；如果是后者，直接考虑 QSemaphore。
分析读写比例：如果写操作极少且读操作频繁，优先选择 QReadWriteLock；如果读写频率相当或写操作较多，QMutex 更简单高效。
判断是否需要线程间通信：如果线程需要等待某个条件成立（如队列非空、任务完成），则必须使用 QWaitCondition + QMutex 的组合。
考虑超时与可中断性：所有同步原语都支持带超时的尝试操作，但 QWaitCondition 的 wait() 支持被 wake 中断，更适合实现可取消的等待。

操作流程示例：使用 QWaitCondition 实现安全的任务队列

// 头文件
class TaskQueue {
public:
    void push(int task) {
        QMutexLocker locker(&m_mutex);
        m_queue.enqueue(task);
        m_cond.wakeOne();  // 唤醒一个等待线程
    }
    int pop() {
        QMutexLocker locker(&m_mutex);
        while (m_queue.isEmpty()) {
            m_cond.wait(&m_mutex);  // 自动释放锁并等待
        }
        return m_queue.dequeue();
    }
private:
    QQueue<int> m_queue;
    QMutex m_mutex;
    QWaitCondition m_cond;
};

注意 while 循环而非 if，这是为了防止“虚假唤醒”（spurious wakeup）。wait() 返回后，条件可能仍未满足，必须重新检查。

3.3 案例拆解：多线程日志系统与资源池设计

我们设计一个实际场景：一个网络服务器需要同时处理多个客户端连接，每个连接在独立线程中运行，并需要将日志写入共享文件。同时，系统维护一个数据库连接池，限制最大并发连接数为 5。

初始目标与约束：日志写入必须保证完整行不交错；数据库连接池不能超过 5 个并发连接；系统需要优雅关闭，不能有线程卡死。

方案设计：

日志写入使用 QMutex 保护，因为写操作频率高且每次写入时间短，不需要读写锁的复杂度。
数据库连接池使用 QSemaphore，初始计数为 5。每次获取连接前 acquire()，释放后 release()。
系统关闭时，使用 QWaitCondition 通知所有工作线程退出。

关键实现片段：

// 日志写入
void writeLog(const QString& msg) {
    static QMutex logMutex;
    QMutexLocker locker(&logMutex);
    QFile file("server.log");
    if (file.open(QIODevice::Append)) {
        file.write(msg.toUtf8() + "\n");
    }
}

// 数据库连接池
class ConnectionPool {
public:
    ConnectionPool() : m_available(5) {}
    QSqlDatabase acquire() {
        m_available.acquire();
        // 从池中取出连接...
    }
    void release(QSqlDatabase db) {
        // 归还连接到池...
        m_available.release();
    }
private:
    QSemaphore m_available;
};

// 优雅关闭
void shutdown() {
    QMutexLocker locker(&m_stopMutex);
    m_stopFlag = true;
    m_stopCond.wakeAll();  // 唤醒所有等待线程
}

结果与复盘：该方案在 50 个并发线程下运行稳定，日志无交错，数据库连接数始终不超过 5。复盘发现，使用 QSemaphore 比 QMutex + 计数器更简洁，因为信号量天然支持阻塞等待。但需要注意，如果 acquire() 后程序崩溃，信号量计数不会自动恢复，需要 RAII 封装。

3.4 常见误区与总结复盘

误区一：混淆 QMutex 与 QReadWriteLock 的使用场景。在写操作频繁时使用读写锁，反而会因维护读写状态而降低性能。实测表明，当写操作占比超过 30% 时，QMutex 通常更快。

误区二：忘记 QWaitCondition 的虚假唤醒。必须使用 while 循环检查条件，否则可能导致线程在条件不满足时继续执行。

误区三：信号量计数泄漏。如果 acquire() 后发生异常，release() 不会执行，导致资源永久减少。建议使用 RAII 包装。

误区四：死锁。多个锁的加锁顺序不一致会导致死锁。例如线程 A 持有锁 1 等待锁 2，线程 B 持有锁 2 等待锁 1。解决方法是始终按相同顺序加锁，或使用 QMutexLocker 等 RAII 类。

经验总结：

优先使用 QMutexLocker、QReadLocker、QWriteLocker 等 RAII 类，避免手动 unlock 遗漏。
对于读多写少的场景，QReadWriteLock 可以显著提升并发性能，但要注意写饥饿问题。
QSemaphore 的初始值应等于资源总数，且 release() 的调用次数必须与 acquire() 匹配。
QWaitCondition 的 wait() 必须传入已加锁的 QMutex，且条件检查必须放在 while 循环中。
在性能敏感代码中，优先使用 tryLock 系列方法，避免无限期阻塞。

通过本章的学习，我们掌握了四种同步原语的原理、适用场景和操作要点。在实际项目中，往往需要组合使用它们：例如用 QMutex 保护共享状态，用 QSemaphore 控制并发度，用 QWaitCondition 实现事件通知。理解每种工具的本质，才能在设计多线程架构时做出正确选择，避免死锁、竞态和性能瓶颈。