C++ std::unique_lock和lock_guard哪个好-C++-PHP中文网

std::lock_guard和std::unique_lock无绝对优劣，选错导致语义错误而非性能问题：前者仅适用于作用域内连续持锁场景，后者必须用于condition_variable::wait、临时解锁、延迟加锁或转移锁所有权等编译强制需求。

c++ std::unique_lock和lock_guard哪个好

std::lock_guard 和 std::unique_lock 没有绝对“哪个好”，选错不是性能问题，而是语义错误——用 std::lock_guard 去配 std::condition_variable::wait() 会编译失败；用 std::unique_lock 守护一行 push_back() 则是过度设计。

什么时候必须用 `std::unique_lock`

不是“推荐”，而是“不这么写就过不了编译”：

std::condition_variable::wait() 的第一个参数类型固定为 std::unique_lock<mutex></mutex> ——std::lock_guard 不满足接口要求，传进去直接报错：no known conversion from 'std::lock_guard<:mutex>' to 'std::unique_lock<:mutex>'</:mutex></:mutex>
需要在临界区内临时释放锁（比如调用可能阻塞的 I/O 或网络函数），再重新加锁：只有 std::unique_lock 提供 unlock() 和 lock() 成员函数
要延迟加锁（例如先检查某个条件是否成立，再决定是否进临界区）：用 std::unique_lock<:mutex> lk(mtx, std::defer_lock)</:mutex> 构造后不锁，后续按需 lk.lock()
需要把锁所有权移出当前作用域（如函数返回一个带锁状态的对象）：std::unique_lock 支持移动，std::lock_guard 不可移动、不可拷贝

什么时候优先用 `std::lock_guard`

它不是“简化版 std::unique_lock”，而是专为一种模式优化的工具：

临界区逻辑连续、无分支、无中途释放需求（例如保护一个 std::vector::push_back() 或简单计数器自增）
锁的作用域和代码块完全对齐——进作用域即加锁，出作用域即解锁，不需要任何干预
声明为局部变量（绝不要作为类成员）：它的生命周期必须短且确定；一旦被长期持有（比如存在类字段里），会导致锁被意外延长，引发性能瓶颈甚至死锁
配合 std::scoped_lock（C++17）同时锁定多个互斥量时，std::lock_guard 无法做到，但这是 std::scoped_lock 的职责，不是 std::lock_guard 的缺陷

常见误用与编译错误

新手最容易栽在这几个点上：

C函数速查手册（CHM版）

下载

对 std::lock_guard 调用 unlock()：编译报错 has no member named 'unlock'，因为它根本没这个函数
默认构造一个 std::unique_lock（不传互斥量）然后直接 lock()：运行时崩溃，因为内部指针为空；必须先绑定有效 std::mutex 实例
把 std::unique_lock 当成“更高级的 std::lock_guard”无脑替换：增加不必要的状态跟踪开销，且容易因忘记 unlock() 或重复 lock() 引发逻辑错误
在循环内反复构造 std::unique_lock 却没意识到每次构造/析构都有轻微开销——虽然纳秒级，但在高频路径上叠加起来并不免费