17370845950

std::lock_guard适用于进作用域加锁、出作用域解锁的简单场景，仅支持自动加锁/解锁，不支持手动控制；std::unique_lock则支持延迟加锁、手动unlock、条件变量协作及移动语义，适用于复杂同步需求。

std::lock_guard 适合「进作用域就加锁、出作用域就解锁」的简单场景

它只做一件事：构造时调用 mutex.lock()，析构时调用 mutex.unlock()，不支持手动解锁、延迟加锁或转移所有权。如果你的临界区逻辑是连续的、无分支跳转、也不需要中途释放锁（比如为了调用可能阻塞的函数），std::lock_guard 是最轻量且最不容易出错的选择。

常见错误现象：有人试图对 std::lock_guard 调用 unlock() 或 release() —— 这些成员函数根本不存在，编译直接报错：error: 'class std::lock_guard<:mutex>' has no member named 'unlock'。

实操建议：

• 优先用于函数内短小、确定性的临界区，例如保护一个 std::vector 的 push_back() 操作
• 配合 std::scoped_lock（C++17）一起用，能安全地同时锁定多个互斥量，避免死锁
• 不要把它声明为类成员变量——它的生命周期必须严格绑定到某一段代码块，否则会导致锁持有时间远超预期

std::unique_lock 支持延迟加锁、手动解锁和条件变量协作

它比 std::lock_guard 多一层抽象：内部持有对互斥量的可选引用，并记录当前是否已上锁。这意味着你可以控制加锁时机（比如先构造再调用 lock()）、主动 unlock()、甚至把锁“移动”给另一个 std::unique_lock 实例（但原实例变为空状态）。

使用场景集中在两类：一是需要在加锁前做判断或准备（如检查某个条件是否满足再决定是否进入临界区）；二是必须与 std::condition_variable 配合——因为 wait() 要求传入一个可手动解锁的锁对象，std::lock_guard 不满足这个接口契约。

实操建议：

• 和 std::condition_variable::wait() 一起使用时，必须用 std::unique_lock
• 若需在临界区内调用可能长时间阻塞的函数（如 I/O 或网络请求），应先 unlock() 再调用，避免锁粒度过大
• 注意默认构造的 std::unique_lock 是“未关联任何互斥量”的空状态，此时调用 lock() 会崩溃；必须先通过赋值或构造函数绑定有效互斥量

性能差异几乎可以忽略，但语义误用会导致严重 bug

两者底层都只是管理一个互斥量指针和一个布尔标记（是否已加锁），没有动态内存分配。构造/析构开销差异在纳秒级，完全不该成为选型依据。真正影响系统行为的是语义误用。

容易踩的坑：

• 把 std::unique_lock 当成更“高级”的 std::lock_guard 来滥用：比如全程不用 unlock()、也不配合条件变量，却多写了一行模板参数，徒增可读性负担
• 在 lambda 或异步回调中捕获了持有锁的 std::unique_lock，结果锁的生命周期被延长到回调执行时——而此时原始作用域早已退出，导致悬空或重复解锁
• 误以为 std::unique_lock 的移动语义能“传递锁的所有权”——实际上它只是转移管理权，底层互斥量仍是共享的；两个 std::unique_lock 同时指向同一 std::mutex 并尝试加锁，依然会阻塞或抛异常（取决于互斥量类型）

一个典型对比示例：生产者-消费者中的锁使用

下面这段代码展示了两种锁在实际协作逻辑中的不可替代性：

std::queue buffer;
std::mutex mtx;
std::condition_variable cv;

// 生产者：用 unique_lock + wait_for 避免忙等
void producer() {
    std::unique_lock lk(mtx);
    while (buffer.size() >= MAX_SIZE) {
        if (cv.wait_for(lk, 100ms) == std::cv_status::timeout) {
            return; // 超时退出
        }
    }
    buffer.push(42);
    lk.unlock(); // 主动释放，避免阻塞消费者
    cv.notify_one();
}

// 消费者：同样需要 unique_lock 才能 wait
void consumer() {
    std::unique_lock lk(mtx);
    cv.wait(lk, []{ return !buffer.empty(); });
    int val = buffer.front();
    buffer.pop();
    // 自动析构时 unlock
}

这里如果把 std::unique_lock 换成 std::lock_guard，第一行 cv.wait(lk, ...) 就无法编译——因为 wait 要求锁对象提供 unlock() 和 lock() 成员函数。

真正该纠结的不是“哪个好”，而是“我此刻要解决什么同步问题”。锁不是越灵活越好，而是刚好够用、不易误用的那个才最好。