必须用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 至少多一个布尔标志位（记录是否持有锁），部分实现还带可选的超时支持逻辑。但这个差异微乎其微，除非在极高频短临界区里反复构造/析构锁对象。真正影响性能的是使用方式：
立即学习“C++免费学习笔记（深入）”；
- 用
unique_lock做不必要的unlock()/lock()切换，可能引发多次系统调用 - 误用
std::adopt_lock（假设 mutex 已被当前线程持有）却没提前加锁，导致未定义行为 - 把
unique_lock拷贝（编译不过）或忘记移动语义，在返回锁对象时出错
常见错误：condition_variable 等待时传错锁类型
这是最典型的编译错误之一：std::condition_variable::wait() 只接受 unique_lock<Mutex>，传 lock_guard 会直接报错：
std::mutex mtx;
std::condition_variable cv;
std::queue<int> data_queue;
// ❌ 错误：lock_guard 不能用于 wait
{
std::lock_guard<std::mutex> lk(mtx);
cv.wait(lk, []{ return !data_queue.empty(); }); // 编译失败
}
// ✅ 正确：必须用 unique_lock
{
std::unique_lock<std::mutex> lk(mtx);
cv.wait(lk, []{ return !data_queue.empty(); }); // ok
}
根本原因在于 wait() 内部需要临时释放锁并原子地进入等待状态，这要求锁对象能响应“放弃所有权”操作——只有 unique_lock 提供 release() 和可移动性支持。
实际写并发逻辑时，别纠结“哪个更‘高级’”，先看需求：只要求 RAII 自动管理，就用 lock_guard；一旦涉及等待、延迟、转移或条件判断，unique_lock 就不是可选项，而是必需品。它的复杂度藏在接口里，不在运行时。
