C++如何使用std::unique_lock和std::lock

std::lock_guard适用于固定作用域的简单锁管理，而std::unique_lock提供延迟锁定、手动控制、条件变量配合等高级特性，适用于复杂同步场景。

c++如何使用std::unique_lock和std::lock_guard

在C++多线程编程中，

std::unique_lock

登录后复制

和

std::lock_guard

登录后复制

都是用于管理互斥锁（

std::mutex

登录后复制

）的RAII（Resource Acquisition Is Initialization）封装器，它们的核心目标都是确保在代码块结束时自动释放锁，从而避免死锁和资源泄露。简单来说，

std::lock_guard

登录后复制

提供了一种简单、直接的锁管理方式，适用于大多数固定范围的锁定需求；而

std::unique_lock

登录后复制

则更为灵活和强大，允许延迟锁定、条件变量配合、所有权转移以及更细粒度的锁操作控制。

在C++中处理多线程同步，互斥锁（

std::mutex

登录后复制

）是基础。但直接调用

lock()

登录后复制

和

unlock()

登录后复制

很容易忘记

unlock()

登录后复制

，尤其是在异常发生时，这就可能导致死锁。

std::lock_guard

登录后复制

和

std::unique_lock

登录后复制

的出现，就是为了解决这个问题，它们通过RAII机制，在构造时获取锁，在析构时自动释放锁，极大地简化了锁的管理。

std::lock_guard

登录后复制

的用法非常直接，它在构造时尝试锁定其关联的互斥锁，并在其生命周期结束（通常是超出其作用域）时自动解锁。这意味着一旦你创建了一个

std::lock_guard

登录后复制

对象，它就会一直持有锁直到它被销毁。这对于那些需要简单、可靠地在某个代码块内保护共享资源的情况来说，是完美的选择。

#include <iostream>
#include <mutex>
#include <thread>
#include <vector>

std::mutex my_mutex;
int shared_data = 0;

void increment_data() {
    // std::lock_guard 会在构造时锁定 my_mutex
    // 并在函数返回（包括异常）时自动解锁
    std::lock_guard<std::mutex> lock(my_mutex); 
    for (int i = 0; i < 1000; ++i) {
        shared_data++;
    }
    // 无需手动调用 my_mutex.unlock();
}

// int main() {
//     std::vector<std::thread> threads;
//     for (int i = 0; i < 10; ++i) {
//         threads.emplace_back(increment_data);
//     }
//     for (auto& t : threads) {
//         t.join();
//     }
//     std::cout << "Final shared_data: " << shared_data << std::endl; // 期望 10000
//     return 0;
// }

登录后复制

std::unique_lock

登录后复制

同样是RAII的，它也能在构造时锁定互斥锁，并在析构时释放。但与

lock_guard

登录后复制

不同的是，

unique_lock

登录后复制

提供了更多的灵活性。它允许你延迟锁定（即在构造时不立即锁定），可以在持有锁期间手动解锁和重新锁定，甚至可以将锁的所有权转移给另一个

unique_lock

登录后复制

对象。这种灵活性在处理一些复杂的同步场景时显得尤为重要，比如与

std::condition_variable

登录后复制

配合使用。

立即学习“C++免费学习笔记（深入）”；

#include <iostream>
#include <mutex>
#include <thread>
#include <condition_variable>

std::mutex mtx;
std::condition_variable cv;
bool ready = false;

void worker_thread() {
    std::unique_lock<std::mutex> lock(mtx); // 构造时锁定
    std::cout << "Worker: Waiting..." << std::endl;
    cv.wait(lock, []{ return ready; }); // 等待期间会自动释放锁，被唤醒时重新获取锁
    std::cout << "Worker: Ready and working!" << std::endl;
    // ... 执行一些操作 ...
    lock.unlock(); // 手动解锁，如果需要提前释放锁
    std::cout << "Worker: Lock released early." << std::endl;
    // ... 执行不需锁保护的操作 ...
    lock.lock(); // 再次锁定
    std::cout << "Worker: Lock reacquired." << std::endl;
    // ...
}

void main_thread() {
    std::this_thread::sleep_for(std::chrono::seconds(1));
    std::unique_lock<std::mutex> lock(mtx);
    ready = true;
    std::cout << "Main: Notifying worker." << std::endl;
    cv.notify_one();
    // lock 在这里作用域结束时自动解锁
}

// int main() {
//     std::thread t1(worker_thread);
//     std::thread t2(main_thread);
//     t1.join();
//     t2.join();
//     return 0;
// }

登录后复制

std::lock_guard

登录后复制

究竟适用于哪些场景？它的局限性在哪里？

在我看来，

std::lock_guard

登录后复制

是最常见也是最推荐的锁管理方式，尤其是在你需要一个明确的、固定作用域的临界区时。它的设计哲学就是“简单即是力量”。当你只需要确保一个特定的代码块在任何时候都只有一个线程访问时，

lock_guard

登录后复制

几乎是你的首选。比如，更新共享计数器、修改共享数据结构、或者执行任何需要原子性操作的代码段。

适用场景：

简单的临界区保护： 这是最典型的用法。任何时候你有一个函数或一个代码块需要独占访问某个共享资源，
```
lock_guard
```
登录后复制
都能提供简洁而可靠的保护。
避免忘记解锁： RAII的特性保证了锁会在
```
lock_guard
```
登录后复制
对象销毁时自动释放，无论是正常退出作用域还是通过异常跳出，这大大降低了死锁的风险。
性能要求不极致，但可靠性优先：
```
lock_guard
```
登录后复制
的开销非常小，因为它不提供额外的功能，这使得它在大多数场景下性能表现良好。

局限性： 尽管

lock_guard

登录后复制

很好用，但它的简单性也意味着功能上的限制。

无法延迟锁定：
```
lock_guard
```
登录后复制
在构造时就尝试获取锁，你无法让它先构造出来，然后过一段时间再尝试锁定。这意味着你不能用它来实现“先准备好，等时机成熟再锁”的模式。
无法手动解锁和重新锁定： 一旦
```
lock_guard
```
登录后复制
构造并获取了锁，它就会一直持有锁直到析构。你不能在它的生命周期内提前释放锁，做一些不需要锁保护的操作，然后再重新获取锁。这对于那些需要短暂释放锁以允许其他线程执行，然后又需要重新获取锁的复杂逻辑来说，就显得捉襟见肘了。
不能与
std::condition_variable
登录后复制
配合：
```
std::condition_variable::wait()
```
登录后复制
方法需要一个
```
std::unique_lock
```
登录后复制
对象作为参数，因为它需要在等待时释放锁，并在被唤醒时重新获取锁。
```
lock_guard
```
登录后复制
不具备这种能力。
不支持所有权转移：
```
lock_guard
```
登录后复制
不可移动也不可复制，你无法将一个
```
lock_guard
```
登录后复制
对象（及其管理的锁）的所有权从一个作用域传递到另一个作用域，或从一个函数返回。

为什么说

std::unique_lock

登录后复制

更灵活？它提供了哪些

lock_guard

登录后复制

不具备的高级特性？

我个人觉得，

std::unique_lock

登录后复制

的“独特”之处，就在于它赋予了程序员对锁操作更精细的控制力。它不仅仅是一个RAII包装器，更是一个功能丰富的锁管理工具，这使得它在处理一些更复杂的并发模式时显得不可或缺。

lock_guard

登录后复制

不具备的高级特性：

延迟锁定（Deferred Locking）：

unique_lock

登录后复制

允许你在构造时指定不立即锁定，而是通过

std::defer_lock

登录后复制

标签。这意味着你可以先创建一个

unique_lock

登录后复制

对象，然后在需要的时候再手动调用

lock()

登录后复制

方法来获取锁。这在某些情况下非常有用，比如你可能需要先进行一些准备工作，或者需要尝试同时锁定多个互斥量（使用

std::lock()

登录后复制

函数），避免死锁。

std::mutex m1, m2;
void complex_operation() {
    std::unique_lock<std::mutex> ul1(m1, std::defer_lock); // 构造时不锁定
    std::unique_lock<std::mutex> ul2(m2, std::defer_lock); // 构造时不锁定

    // 使用 std::lock 尝试同时锁定多个互斥量，避免死锁
    std::lock(ul1, ul2); // 成功锁定 ul1 和 ul2

    // ... 临界区操作 ...
    std::cout << "Both locks acquired." << std::endl;
    // ul1 和 ul2 在这里作用域结束时自动解锁
}

登录后复制

手动解锁和重新锁定：
```
unique_lock
```
登录后复制
提供了
```
lock()
```
登录后复制
和
```
unlock()
```
登录后复制
成员函数，允许你在其生命周期内手动控制锁的状态。这在某些情况下非常有用，例如，你可能在临界区内执行了一部分操作后，发现接下来的操作不需要锁的保护，就可以提前释放锁，让其他线程有机会获取锁，从而提高并发性。之后如果需要，可以再次锁定。

如知AI笔记
如知笔记——支持markdown的在线笔记，支持ai智能写作、AI搜索，支持DeepseekR1满血大模型

27

查看详情
```
std::mutex mtx_manual;
void process_data_with_manual_lock() {
    std::unique_lock<std::mutex> lock(mtx_manual); // 构造时锁定
    // ... 临界区操作 A ...
    std::cout << "Phase A completed with lock." << std::endl;

    lock.unlock(); // 提前释放锁
    // ... 执行不需要锁保护的操作 B ...
    std::cout << "Phase B completed without lock." << std::endl;

    lock.lock(); // 重新获取锁
    // ... 临界区操作 C ...
    std::cout << "Phase C completed with lock again." << std::endl;
}
```
登录后复制

条件变量（

std::condition_variable

登录后复制

）的配合： 这是

unique_lock

登录后复制

最重要的应用场景之一。

std::condition_variable::wait()

登录后复制

方法需要一个

std::unique_lock

登录后复制

对象作为参数。在等待时，

wait()

登录后复制

会原子性地释放锁并阻塞当前线程；当条件满足被唤醒时，它会重新获取锁并返回。

lock_guard

登录后复制

无法做到这一点，因为它不能在运行时释放和重新获取锁。

std::mutex cv_mtx;
std::condition_variable cv_var;
bool data_ready = false;

void consumer() {
    std::unique_lock<std::mutex> lock(cv_mtx);
    cv_var.wait(lock, []{ return data_ready; }); // 等待并释放锁，唤醒时重新获取
    std::cout << "Consumer: Data is ready, processing..." << std::endl;
    // ... 处理数据 ...
}

void producer() {
    std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 模拟生产时间
    std::unique_lock<std::mutex> lock(cv_mtx);
    data_ready = true;
    std::cout << "Producer: Data produced, notifying consumer." << std::endl;
    cv_var.notify_one();
}

登录后复制

尝试锁定（Try Locking）和定时锁定（Timed Locking）：

unique_lock

登录后复制

提供了

try_lock()

登录后复制

、

try_lock_for()

登录后复制

和

try_lock_until()

登录后复制

方法，允许你尝试在不阻塞当前线程的情况下获取锁，或者在指定时间内尝试获取锁。这对于实现非阻塞的并发算法或带有超时机制的锁获取逻辑非常有用。

std::mutex mtx_try;
void try_lock_example() {
    std::unique_lock<std::mutex> lock(mtx_try, std::defer_lock); // 延迟锁定
    if (lock.try_lock()) { // 尝试非阻塞地获取锁
        std::cout << "Successfully acquired lock." << std::endl;
        // ... 临界区操作 ...
    } else {
        std::cout << "Failed to acquire lock immediately." << std::endl;
    }

    // 尝试在100毫秒内获取锁
    if (lock.try_lock_for(std::chrono::milliseconds(100))) {
        std::cout << "Acquired lock within 100ms." << std::endl;
    } else {
        std::cout << "Failed to acquire lock within 100ms." << std::endl;
    }
}

登录后复制

所有权转移（Move Semantics）：

unique_lock

登录后复制

是可移动的（Moveable），但不可复制（Non-copyable）。这意味着你可以将一个

unique_lock

登录后复制

对象的所有权从一个函数返回，或者传递给另一个函数，而不会造成额外的锁操作或资源泄漏。这在一些工厂函数或需要将锁管理职责转移的场景中非常有用。

std::unique_lock<std::mutex> get_locked_resource(std::mutex& m) {
    std::unique_lock<std::mutex> lock(m);
    // ... 执行一些初始化操作 ...
    return lock; // 返回 unique_lock，所有权转移
}

// void use_resource() {
//     std::mutex my_m;
//     std::unique_lock<std::mutex> current_lock = get_locked_resource(my_m);
//     // current_lock 现在持有锁
//     std::cout << "Resource acquired and locked in main." << std::endl;
// }

登录后复制

在实际开发中，我应该如何选择

std::unique_lock

登录后复制

还是

std::lock_guard

登录后复制

？有没有什么“最佳实践”？

选择

std::unique_lock

登录后复制

还是

std::lock_guard

登录后复制

，这其实是一个权衡问题，主要看你的具体需求和对锁管理复杂度的接受程度。我个人在实践中，会遵循一些经验法则，这能帮助我快速做出决策。

我的“最佳实践”和选择指南：

优先选择
```
std::lock_guard
```
登录后复制
：
- 简单性原则： 如果你的需求仅仅是在一个明确的、固定的代码块内保护共享资源，并且不需要任何高级的锁操作（如延迟锁定、手动解锁、条件变量等），那么
```
std::lock_guard
```
  登录后复制
  应该是你的首选。它代码更简洁，意图更清晰，也更不容易出错。
- 性能考量： 虽然现代编译器对
```
unique_lock
```
  登录后复制
  的优化已经很好了，但在极度性能敏感的场景下，
```
lock_guard
```
  登录后复制
  理论上会带来更低的运行时开销，因为它不需要维护额外的状态（比如锁是否被持有）。当然，这种差异通常微乎其微，不应成为主要决策因素，但作为一种“保守”的选择，它总是稳妥的。
- 默认选择： 我通常会把
```
lock_guard
```
  登录后复制
  作为我的默认选择。只有当它不能满足我的需求时，我才会考虑
```
unique_lock
```
  登录后复制
  。
何时考虑
```
std::unique_lock
```
登录后复制
：
- 与
  std::condition_variable
  登录后复制
  配合：这是使用
```
unique_lock
```
  登录后复制
  最常见的场景，几乎是强制性的。如果你需要使用条件变量进行线程间的等待和通知，那么
```
unique_lock
```
  登录后复制
  是唯一的选择。
- 延迟锁定或尝试锁定： 当你需要先创建锁对象，但不想立即阻塞，或者希望在一定时间内尝试获取锁（例如，避免长时间阻塞，或者实现无锁算法的备用方案），
```
unique_lock
```
  登录后复制
  的
```
std::defer_lock
```
  登录后复制
  、
```
try_lock()
```
  登录后复制
  或
```
try_lock_for()
```
  登录后复制
  /
```
try_lock_until()
```
  登录后复制
  就派上用场了。
- 细粒度控制锁的生命周期： 如果你在一个函数内部，需要执行一部分临界区操作，然后释放锁执行一些非临界区操作，再重新获取锁执行另一部分临界区操作，那么
```
unique_lock
```
  登录后复制
  的
```
unlock()
```
  登录后复制
  和
```
lock()
```
  登录后复制
  方法就非常方便。这有助于在不影响正确性的前提下，最大化并发度。
- 锁的所有权转移： 当你需要将锁的控制权从一个函数传递到另一个函数，或者从一个对象传递给另一个对象时，
```
unique_lock
```
  登录后复制
  的移动语义是不可或缺的。
- 复杂资源管理： 在设计一些更复杂的同步机制时，
```
unique_lock
```
  登录后复制
  提供的灵活性往往能让你更好地构建和控制。