优先选std::unique_lock，因其支持延迟加锁、手动解锁、条件变量等待和锁所有权转移；仅当只需raii式自动加解锁时用更轻量的std::lock_guard。
std::unique_lock 和 std::lock_guard 用哪个？
绝大多数情况下，优先选 std::unique_lock —— 它不是“更高级的 lock_guard”，而是解决不同问题的工具。当你只需要进作用域加锁、出作用域解锁，std::lock_guard 更轻量、无开销；但只要涉及「延迟加锁」「手动释放锁」「配合条件变量」或「转移锁所有权」，就必须用 std::unique_lock。
什么时候必须用 std::unique_lock 而不是 lock_guard？
std::lock_guard 构造即加锁、析构即释放，不可拆分；std::unique_lock 把加锁、解锁、转移、检查状态都暴露出来。典型场景包括：
- 需要先构造锁对象，稍后再调用
lock()（比如根据某个条件决定是否加锁） - 在函数中提前
unlock()，释放锁后继续执行非临界区代码（避免锁粒度过大） - 和
std::condition_variable::wait()配合：wait 会原子地释放锁并挂起，唤醒时重新加锁，只有std::unique_lock支持这种语义 - 把锁所有权移交给另一个
std::unique_lock对象（如返回锁、传参）
std::unique_lock 的常见误用和坑
最容易踩的坑是忽略其默认行为：std::unique_lock 默认构造时不持有锁（std::defer_lock），而 std::lock_guard 默认构造就加锁。不显式指定策略，容易误以为“已上锁”却没上：
// ❌ 错误：my_lock 构造后未加锁，下面访问共享资源会数据竞争 std::mutex mtx; std::unique_lock<:mutex> my_lock(mtx); // 等价于 std::unique_lock<:mutex> my_lock(mtx, std::defer_lock); shared_data = 42; // 危险！ // ✅ 正确写法之一：显式加锁 std::unique_lock<:mutex> my_lock(mtx, std::defer_lock); my_lock.lock(); // 手动加锁 shared_data = 42; my_lock.unlock(); // 手动释放 // ✅ 或直接构造即加锁（等价于 lock_guard 行为） std::unique_lock<:mutex> my_lock(mtx); // 默认是 defer_lock，所以这行实际不加锁！ // 正确写法应为： std::unique_lock<:mutex> my_lock(mtx, std::defer_lock); // 显式声明意图 // 或更常用： std::unique_lock<:mutex> my_lock(mtx); // ❌ 错！这里仍不加锁 // ✅ 应写成： std::unique_lock<:mutex> my_lock(mtx, std::try_to_lock); // 尝试加锁 // 或干脆： std::unique_lock<:mutex> my_lock(mtx); // ⚠️ 注意：这个写法在 C++17 后仍不加锁！必须传策略</:mutex></:mutex></:mutex></:mutex></:mutex></:mutex></:mutex></:mutex>
另一个坑是误用 std::adopt_lock：它表示“当前线程已持有该 mutex，只需接管管理权”，但如果你没提前调用 mtx.lock() 就传 std::adopt_lock，行为未定义。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
性能和移动语义要注意什么？
std::unique_lock 支持移动（move），但不支持拷贝（copy）——这是设计使然，避免意外复制导致多个对象管理同一把锁。这意味着：
- 可以安全地从函数返回
std::unique_lock（返回时触发移动） - 不能把它存进
std::vector<:unique_lock>></:unique_lock>（因为 vector 可能重分配并拷贝元素） - 传递给函数时，建议用右值引用或直接移动：
process(std::move(my_lock)) - 移动后原对象变为“未关联状态”，调用
owns_lock()返回 false，再次lock()是合法的
性能上，std::unique_lock 比 std::lock_guard 多一个布尔成员记录是否持锁，内存开销极小（通常 1–2 个字节），但构造/析构路径稍长。日常使用无需担心，除非在极高频短临界区且确定不需要延迟锁控 —— 那才考虑 std::lock_guard。
真正容易被忽略的是：std::unique_lock 的析构函数会调用 unlock()，但前提是它当前拥有锁（owns_lock() == true）。如果中途手动 unlock() 过，析构就什么都不做 —— 这点和 lock_guard 的“必然释放”不同，得自己心里有数。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
