C++ unique_lock怎么配合条件变量使用-C++-PHP中文网

unique_lock构造后必须已加锁才能wait，否则抛异常；wait需用while而非if以防虚假唤醒；notify应在同一锁内更新状态以保证可见性；adopt_lock仅用于已持锁时移交管理权。

c++ unique_lock怎么配合条件变量使用

为什么不能直接用 `unique_lock` 构造完就 wait？

因为 condition_variable::wait 要求传入的 unique_lock 必须处于「已加锁」状态，且该锁必须和条件变量关联的互斥量类型一致（通常是 std::mutex）。如果构造 unique_lock 时不加锁（比如用 std::defer_lock），或者锁在 wait 前被意外释放，wait 会抛出 std::system_error，错误信息通常是 operation not permitted 或 invalid argument。

常见错误写法：

std::mutex mtx;
std::condition_variable cv;
std::unique_lock<:mutex> lk(mtx, std::defer_lock); // 没锁！
cv.wait(lk, []{ return ready; }); // 运行时报错
</:mutex>

正确做法是：确保 lk 在调用 wait 前已持有锁——通常直接默认构造或传 std::try_to_lock 后检查。

`wait` 里为什么要用 while 而不是 if？

虚假唤醒（spurious wakeup）是 POSIX 和 C++ 标准允许的行为：wait 可能在没有 notify_one/notify_all 的情况下返回。如果只用 if 判断一次，线程可能在条件未满足时继续执行，导致逻辑错误。

实操建议：

始终用 while 循环检查谓词，而不是 if
谓词必须是无副作用、轻量的 lambda 或函数对象
避免在谓词里做耗时操作（比如 IO、锁其他资源）

示例：

bool ready = false;
// ...
std::unique_lock<:mutex> lk(mtx);
while (!ready) {
    cv.wait(lk); // 自动释放锁 → 等待 → 被唤醒后重新加锁
}
// 此时 ready 为 true，且 lk 仍持有 mtx
</:mutex>

notify 一定要在锁住同一互斥量的情况下调用吗？

不是强制要求，但强烈建议这么做。原因有二：

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

一是避免竞态：如果 notify 在修改共享状态（如 ready = true）前没加锁，等待线程可能在 wait 返回后读到旧值；二是提升可预测性——notify 不会立即唤醒线程，只是“标记可唤醒”，真正调度由系统决定。若通知和状态更新不同步，容易漏唤醒。

典型安全模式：

std::unique_lock<:mutex> lk(mtx);
ready = true;
cv.notify_one(); // 在锁内 notify，保证 ready 对等待线程可见
</:mutex>

注意：notify_one 和 notify_all 本身不操作互斥量，也不要求锁已持有，但配合状态更新时，锁是必要的同步手段。

什么时候该用 `std::adopt_lock`？

当你已经持有了互斥量，想把所有权转移给 unique_lock（比如在函数参数传递或跨作用域管理时），才用 std::adopt_lock。它不会尝试加锁，只是告诉 unique_lock：“这把锁我已拿着，请接管管理权”。

误用场景很多，比如：

std::mutex mtx;
mtx.lock();
std::unique_lock<:mutex> lk(mtx, std::adopt_lock); // ✅ 正确：已锁，移交管理
// ...
mtx.unlock(); // ❌ 错误：lk 析构时会自动 unlock，这里再 unlock 是 double-unlock UB
</:mutex>

关键点：