在C++多线程开发中，互斥锁是保护共享资源的核心工具，而unique_lock和lock_guard是标准库提供的两种锁管理类，都基于RAII机制实现锁的自动获取和释放，避免手动操作锁带来的遗漏解锁、异常场景下死锁等问题。不过两者的设计目标不同，灵活性差异很大，需要根据实际场景选择使用。
基本特性对比
首先通过核心特性对比，快速了解两者的差异：
| 特性 | lock_guard | unique_lock |
|---|---|---|
| 是否支持延迟加锁 | 不支持，构造时必须获取锁 | 支持，可传入std::defer_lock参数延迟加锁 |
| 是否支持手动解锁 | 不支持，生命周期结束才释放锁 | 支持，可调用unlock()手动释放 |
| 是否支持所有权转移 | 不支持，不可移动不可拷贝 | 支持，可移动不可拷贝 |
| 是否适配条件变量 | 不兼容 | 兼容，可作为std::condition_variable的等待参数 |
| 性能开销 | 极小，几乎无额外开销 | 略高，内部需要维护锁状态 |
lock_guard的使用场景与示例
lock_guard的设计非常简洁，构造时自动获取锁，析构时自动释放锁，生命周期内无法手动操作锁，适合逻辑简单、不需要中途释放锁的场景，比如普通的共享资源修改。
下面是一个简单的计数器多线程修改示例，使用lock_guard保护共享变量：
#include <iostream>
#include <thread>
#include <mutex>
#include <vector>
std::mutex g_mutex;
int g_counter = 0;
void increment_counter() {
// 构造lock_guard时自动获取g_mutex锁
std::lock_guard<std::mutex> lock(g_mutex);
// 临界区操作，修改共享变量
for (int i = 0; i < 1000; i++) {
g_counter++;
}
// lock离开作用域，析构时自动释放g_mutex锁
}
int main() {
std::vector<std::thread> threads;
for (int i = 0; i < 10; i++) {
threads.emplace_back(increment_counter);
}
for (auto& t : threads) {
t.join();
}
std::cout << "最终计数器值: " << g_counter << std::endl;
return 0;
}
这个场景中，临界区的逻辑是连续的，不需要中途释放锁，使用lock_guard足够，且性能开销更小。如果尝试在lock_guard生命周期内调用unlock()，或者将其赋值给其他变量，都会直接编译报错。
unique_lock的使用场景与示例
unique_lock的灵活性更高，支持更多复杂场景，比如需要延迟加锁、中途释放锁、配合条件变量使用，或者需要将锁的所有权转移到其他函数/作用域。
场景1：延迟加锁与手动解锁
当需要先获取锁之外的其他资源，再获取锁进入临界区，或者临界区中只有部分逻辑需要加锁时，可以使用unique_lock的延迟加锁和手动解锁特性：
#include <iostream>
#include <mutex>
#include <thread>
std::mutex g_mutex;
int g_data = 0;
void process_data() {
// 延迟加锁，构造时不获取锁，传入std::defer_lock参数
std::unique_lock<std::mutex> lock(g_mutex, std::defer_lock);
// 先执行不需要加锁的预处理逻辑
int temp = 10;
// 需要进入临界区时再手动加锁
lock.lock();
g_data += temp;
// 临界区操作完成，手动释放锁，后续逻辑不需要加锁
lock.unlock();
// 执行其他不需要加锁的后处理操作
temp *= 2;
}
int main() {
std::thread t1(process_data);
std::thread t2(process_data);
t1.join();
t2.join();
std::cout << "最终数据值: " << g_data << std::endl;
return 0;
}
场景2：配合条件变量使用
条件变量的wait函数需要释放锁等待通知，被唤醒后重新获取锁，这个逻辑只有unique_lock能够支持，lock_guard无法适配：
#include <iostream>
#include <mutex>
#include <condition_variable>
#include <queue>
#include <thread>
std::mutex g_mutex;
std::condition_variable g_cv;
std::queue<int> g_task_queue;
// 消费者线程函数
void consumer() {
std::unique_lock<std::mutex> lock(g_mutex);
// 等待队列不为空，wait会自动释放锁，被唤醒后重新获取锁
g_cv.wait(lock, []{ return !g_task_queue.empty(); });
// 处理队列中的任务
int task = g_task_queue.front();
g_task_queue.pop();
std::cout << "处理任务: " << task << std::endl;
}
// 生产者线程函数
void producer(int task_id) {
std::unique_lock<std::mutex> lock(g_mutex);
g_task_queue.push(task_id);
lock.unlock(); // 手动释放锁，不需要持有锁再通知条件变量
g_cv.notify_one(); // 通知消费者
}
int main() {
std::thread t1(consumer);
std::thread t2(producer, 1);
t1.join();
t2.join();
return 0;
}
场景3：锁所有权转移
unique_lock支持移动语义，可以将锁的所有权转移到其他作用域，比如函数返回unique_lock，或者将unique_lock作为参数传递：
#include <iostream>
#include <mutex>
std::mutex g_mutex;
// 函数返回unique_lock，转移锁的所有权
std::unique_lock<std::mutex> get_lock() {
std::unique_lock<std::mutex> lock(g_mutex);
// 做一些初始化操作
return lock; // 返回时触发移动构造，转移锁所有权
}
void process_with_lock(std::unique_lock<std::mutex> lock) {
// 这里已经持有锁，直接操作共享资源
std::cout << "持有锁处理资源" << std::endl;
}
int main() {
auto lock = get_lock(); // 接收转移的锁所有权
process_with_lock(std::move(lock)); // 再次转移所有权到函数参数
return 0;
}
选择建议
实际开发中可以根据以下原则选择：
- 如果场景简单，只需要连续的临界区保护，不需要中途释放锁，优先选择
lock_guard，性能更好，代码更简洁。 - 如果需要延迟加锁、手动解锁、配合条件变量使用，或者需要转移锁的所有权，必须使用
unique_lock。 - 不要为了灵活性无脑使用
unique_lock，不必要的灵活性会带来额外的性能开销，也增加了代码的理解成本。
两者都是C++并发编程中非常重要的工具，理解它们的差异和适用场景，能够帮助开发者写出更安全、高效的多线程代码。
C++多线程unique_locklock_guard互斥锁并发编程修改时间：2026-06-09 00:27:33