lock_guard与unique_lock区别解析

std::lock_guard是构造即加锁、析构即解锁的不可复制/移动的RAII锁，适用于简单临界区；std::unique_lock支持延迟锁定、手动解锁、条件变量和所有权转移，更灵活但稍重。

lock_guard 是个“一锤子买卖”，构造即加锁、析构即解锁

它没有移动或复制能力，生命周期完全绑定到作用域——只要定义了 std::lock_guard，就立刻尝试加锁；离开作用域时自动调用析构函数释放锁。适合最简单的临界区保护场景。

常见错误是试图把它当作可转移的对象来用：std::lock_guard 的拷贝构造和移动构造都被显式删除，所以不能放进容器、不能作为函数返回值、也不能赋值给另一个 lock_guard。

使用建议：

• 只在需要“进作用域就锁、出作用域就放”的简单同步时用
• 不要传参给它带 std::defer_lock——它不支持延迟锁定，这个标记只对 std::unique_lock 有效
• 如果临界区里可能抛异常，lock_guard 反而是更安全的选择（因为析构保证释放）

unique_lock 支持延迟锁定、手动解锁、条件变量配合和所有权转移

std::unique_lock 更像一个“可操控的锁句柄”。它允许你控制加锁时机（比如用 std::defer_lock 构造后稍后再调 lock()），也能在临界区中途主动 unlock()，再在必要时 lock() 回来——这对避免锁粒度过大很有用。

典型使用场景包括：

• 与 std::condition_variable 配合：必须用 unique_lock，因为 wait() 要求能临时释放并重获锁
• 实现 try-lock 逻辑：try_lock() 返回 bool，失败也不阻塞
• 把锁所有权移交给另一个作用域（通过移动语义），比如从工厂函数返回已加锁的 unique_lock

注意：它比 lock_guard 稍重（内部多一个布尔状态位），且默认构造时不关联任何互斥量，使用前必须显式绑定或移动赋值。

别混用 defer_lock 和 lock_guard，也别误以为 unique_lock 默认就加锁

这是面试高频踩坑点。写 std::unique_lock lk(mtx, std::defer_lock) 后，lk 是未锁定状态；而写 std::lock_guard lg(mtx) 则必然立即阻塞等待加锁成功（除非抛异常）。

另一个常见误操作是：在 unique_lock 已持有时，又对同一互斥量调用 mtx.lock() ——这会导致未定义行为（通常死锁或崩溃），因为 unique_lock 已接管该 mutex 的所有权。

参数差异要点：

• std::defer_lock → 构造时不加锁
• std::try_to_lock → 构造时非阻塞尝试加锁，失败则对象处于未锁定状态
• std::adopt_lock → 假设当前线程已持有该 mutex，直接接管（常用于先 mtx.lock() 再构造 unique_lock）

性能与可读性权衡：多数情况优先用 lock_guard

除非你明确需要 unique_lock 提供的灵活性，否则默认选 lock_guard。它的语义更清晰、开销更低、且编译器更容易做优化（比如 NRVO 或栈分配消除）。

实际项目中，过度使用 unique_lock 容易带来两类问题：

• 忘记调 lock() 就进入临界区，导致数据竞争（编译器不会报错）
• 在复杂控制流中多次 lock()/unlock()，增加维护成本和出错概率

真正需要手动干预锁生命周期的地方其实不多，比如实现自定义同步原语、或封装跨多个 mutex 的锁顺序逻辑——这时候才值得引入 unique_lock 的额外复杂度。