C++ unique_lock和lock_guard区别 C++多线程锁的灵活性对比【并发】_技术教程

必须用unique_lock而不能用lock_guard的场景包括：需延迟加锁（std::defer_lock）、循环中多次加解锁、配合condition_variable使用、传递锁对象。

什么时候必须用 `unique_lock` 而不能用 `lock_guard`

lock_guard 是个“一创建就加锁、一析构就解锁”的简单封装，不支持手动控制锁的生命周期；unique_lock 则是可移动、可延迟、可条件释放的完整锁管理器。以下场景 lock_guard 完全无法胜任：

需要在构造时不立即加锁（比如传 std::defer_lock）
需要在函数中多次加锁/解锁（例如循环中反复操作临界资源）
要配合 std::condition_variable 使用（wait() 必须传 unique_lock）
要把锁对象作为返回值或参数传递（unique_lock 支持移动，lock_guard 不可复制也不可移动）

`unique_lock` 的三种构造方式和对应行为

它的灵活性正体现在构造参数上，不同参数决定锁的初始状态和所有权：

unique_lock(mutex)：立即调用 mutex.lock()，和 lock_guard 行为一致
unique_lock(mutex, std::defer_lock)：不加锁，后续需手动调用 lock() 或 try_lock()
unique_lock(mutex, std::try_to_lock)：尝试非阻塞加锁，owns_lock() 可查是否成功

注意：std::defer_lock 和 std::try_to_lock 是标记类型（tag types），不是布尔值，写错成 true/false 会编译失败。

性能差异和隐含开销在哪

多数情况下，lock_guard 更轻量——它只存一个指向 mutex 的指针（通常无额外成员），而 unique_lock 至少多一个布尔标志位（记录是否持有锁），部分实现还带可选的超时支持逻辑。但这个差异微乎其微，除非在极高频短临界区里反复构造/析构锁对象。真正影响性能的是使用方式：

用 unique_l ock 做不必要的 unlock()/lock() 切换，可能引发多次系统调用
误用 std::adopt_lock（假设 mutex 已被当前线程持有）却没提前加锁，导致未定义行为
把 unique_lock 拷贝（编译不过）或忘记移动语义，在返回锁对象时出错

常见错误：condition_variable 等待时传错锁类型

这是最典型的编译错误之一：std::condition_variable::wait() 只接受 unique_lock，传 lock_guard 会直接报错：

std::mutex mtx;
std::condition_variable cv;
std::queue data_queue;

// ❌ 错误：lock_guard 不能用于 wait
{
    std::lock_guard lk(mtx);
    cv.wait(lk, []{ return !data_queue.empty(); }); // 编译失败
}

// ✅ 正确：必须用 unique_lock
{
    std::unique_lock lk(mtx);
    cv.wait(lk, []{ return !data_queue.empty(); }); // ok
}

根本原因在于 wait() 内部需要临时释放锁并原子地进入等待状态，这要求锁对象能响应“放弃所有权”操作——只有 unique_lock 提供 release() 和可移动性支持。

实际写并发逻辑时，别纠结“哪个更‘高级’”，先看需求：只要求 RAII 自动管理，就用 lock_guard；一旦涉及等待、延迟、转移或条件判断，unique_lock 就不是可选项，而是必需品。它的复杂度藏在接口里，不在运行时。