C++中的std::unique_lock比lock_guard强在哪里？(支持手动解锁与延迟加锁)

std::unique_lock支持手动unlock、延迟构造、try-lock、move语义及配合condition_variable；std::lock_guard仅RAII自动加锁/解锁，不可干预、不可移动、无状态、更轻量。

std::unique_lock 支持手动 unlock()，lock_guard 完全不支持

这是最直接的差异：std::unique_lock 是可移动、可延迟、可手动控制的锁包装器；而 std::lock_guard 一旦构造就立即加锁，析构时自动释放，中间**无法干预**。如果你需要在临界区中途释放锁（比如等待条件变量、避免锁粒度太粗），只能用 std::unique_lock。

常见错误现象：std::lock_guard 对象在作用域内“想提前放锁”却找不到 unlock() 方法，编译报错：error: 'class std::lock_guard<:mutex>' has no member named 'unlock'。

• 适用场景：调用 std::condition_variable::wait() 必须传入 std::unique_lock，因为 wait 内部会先 unlock，唤醒后再重新 lock
• 手动解锁示例：

  std::mutex mtx;
  std::unique_lock lk(mtx);
  // ... 做一部分受保护操作
  lk.unlock(); // ✅ 合法且必要
  // ... 可能做非临界工作（如 IO、计算），不阻塞其他线程
  lk.lock();   // ✅ 可重新加锁
  // ... 继续临界区操作

std::unique_lock 支持延迟构造和 defer_lock 参数

std::lock_guard 构造即加锁，没有选择；std::unique_lock 可以用 std::defer_lock 标签初始化，不立刻持有锁——这让你能把加锁时机和锁对象生命周期解耦。

使用场景：实现 try-lock、多锁按序获取、或根据运行时条件决定是否加锁。

• std::unique_lock<:mutex> lk(mtx, std::defer_lock); → 构造时不加锁
• if (lk.try_lock()) { /* 成功进入临界区 */ } → 非阻塞尝试
• std::unique_lock<:mutex> lk1(mtx1, std::defer_lock), lk2(mtx2, std::defer_lock); std::lock(lk1, lk2); → 避免死锁的批量加锁

性能与内存开销：unique_lock 更重，但代价通常可接受

std::lock_guard 是零开销抽象：它只是个 RAII 封装，不带状态，sizeof 通常等于一个指针（甚至更小）；std::unique_lock 内部需记录是否已加锁、是否拥有锁等状态，有轻微内存和指令开销。

不过，在绝大多数真实场景中，这点开销远小于锁本身的系统调用或缓存争用成本。别为了省几个字节放弃灵活性——除非你在超低延迟、高频短临界区的嵌入式实时系统里手写锁逻辑。

• 典型 sizeof 差异（x64）：sizeof(std::lock_guard<:mutex>) ≈ 1，sizeof(std::unique_lock<:mutex>) ≈ 16
• 不要用 std::unique_lock 替代 std::lock_guard 仅仅为了“统一风格”——没 unlock / defer / transfer 需求时，std::lock_guard 更清晰、更轻量、意图更明确

unique_lock 支持 move 语义，lock_guard 不可拷贝也不可移动

std::unique_lock 可以 move（比如返回局部锁、传入 lambda 捕获），std::lock_guard 连 move 都被禁用（删除了移动构造函数）。这不是“强弱”问题，而是设计定位不同：前者是锁的“句柄”，后者是“作用域绑定锁”。

容易踩的坑：试图把 std::lock_guard 存进容器、作为函数返回值、或用在需要转移所有权的地方，编译直接失败。

• 合法示例：

  std::unique_lock make_lock(std::mutex& m) {
      return std::unique_lock(m); // ✅ 可移动返回
  }

• 非法示例：std::lock_guard<:mutex> lg(m); auto x = std::move(lg); → 编译错误

真正关键的不是“哪个更强”，而是“你是否需要 unlock、defer、try、move 或配合 condition_variable”。不需要时，std::lock_guard 更安全、更轻、意图更干净；一旦涉及任何动态锁控制，std::unique_lock 就不是可选项，而是唯一解。