std::lock_guard适用于固定作用域的简单锁管理，而std::unique_lock提供延迟锁定、手动控制、条件变量配合等高级特性，适用于复杂同步场景。
在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 #include #include #include std::mutex my_mutex;int shared_data = 0;void increment_data() { // std::lock_guard 会在构造时锁定 my_mutex // 并在函数返回（包括异常）时自动解锁 std::lock_guard lock(my_mutex); for (int i = 0; i < 1000; ++i) { shared_data++; } // 无需手动调用 my_mutex.unlock();}// int main() {// std::vector 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 #include #include #include std::mutex mtx;std::condition_variable cv;bool ready = false;void worker_thread() { std::unique_lock 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 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
究竟适用于哪些场景？它的局限性在哪里？
在我看来，
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
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 ul1(m1, std::defer_lock); // 构造时不锁定 std::unique_lock 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()
成员函数，允许你在其生命周期内手动控制锁的状态。这在某些情况下非常有用，例如，你可能在临界区内执行了一部分操作后，发现接下来的操作不需要锁的保护，就可以提前释放锁，让其他线程有机会获取锁，从而提高并发性。之后如果需要，可以再次锁定。
std::mutex mtx_manual;void process_data_with_manual_lock() { std::unique_lock 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 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 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 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 get_locked_resource(std::mutex& m) { std::unique_lock lock(m); // ... 执行一些初始化操作 ... return lock; // 返回 unique_lock，所有权转移}// void use_resource() {// std::mutex my_m;// std::unique_lock current_lock = get_locked_resource(my_m);// // current_lock 现在持有锁// std::cout << "Resource acquired and locked in main." << std::endl;// }
在实际开发中，我应该如何选择
std::unique_lock
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
提供的灵活性往往能让你更好地构建和控制。
总结一下我的思考过程：
当我面对一个需要锁保护的代码块时，我首先问自己：“我需要条件变量吗？我需要延迟锁定吗？我需要在中途释放锁吗？我需要尝试获取锁吗？我需要转移锁的所有权吗？”
如果所有答案都是“否”，那么
std::lock_guard
是最简单、最清晰、最不易出错的选择。只要其中有一个答案是“是”，那么
std::unique_lock
就是我必须使用的工具。
记住，代码的清晰度和意图的表达同样重要。
lock_guard
明确表示“我只是在这个作用域内保护资源”，而
unique_lock
则暗示着“我可能需要对这个锁进行更复杂的操作”。选择正确的工具，不仅能保证程序的正确性，也能让代码更易于理解和维护。不要为了追求“灵活性”而滥用
unique_lock
，如果
lock_guard
足以解决问题，就用它。过度复杂的解决方案往往会引入新的bug。
以上就是C++如何使用std::unique_lock和std::lock_guard的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1474143.html
微信扫一扫 
支付宝扫一扫 
