一、先问一个问题
如果lock_guard已经够安全了：
- 自动加锁
- 自动解锁
- 异常安全
那为什么 C++ 还要提供：
std::unique_lock答案一句话：
因为工程场景比“简单加锁”复杂得多。
二、lock_guard vs unique_lock 本质区别
| 特性 | lock_guard | unique_lock |
|---|---|---|
| 自动加锁 | ✅ | ✅ |
| 自动解锁 | ✅ | ✅ |
| 可手动 unlock | ❌ | ✅ |
| 可延迟加锁 | ❌ | ✅ |
| 可 try_lock | ❌ | ✅ |
| 可移动 | ❌ | ✅ |
| 性能 | 更轻量 | 略重 |
结论：
默认用 lock_guard
需要控制能力时用 unique_lock
三、工程场景 1：需要“中途释放锁”
假设：
- 你操作共享队列
- 取出任务
- 处理任务需要耗时 3 秒
错误写法：
std::lock_guard<std::mutex> lock(mtx); auto task = queue.front(); queue.pop(); process(task); // ⚠ 锁被持有 3 秒问题：
- 其他线程无法访问队列
- 性能严重下降
正确写法：
std::unique_lock<std::mutex> lock(mtx); auto task = queue.front(); queue.pop(); lock.unlock(); // 手动释放锁 process(task); // 不再阻塞其他线程这就是：
unique_lock 的第一能力：可控释放
四、工程场景 2：延迟加锁 defer_lock
有时你需要：
- 先创建锁对象
- 稍后再决定是否加锁
std::unique_lock<std::mutex> lock(mtx, std::defer_lock); // 这里还没加锁 if (needLock) { lock.lock(); }用途：
- 避免嵌套死锁
- 更灵活的流程控制
Java 对比：
Java 的ReentrantLock可以：
lock.lock(); lock.unlock();但 Java 没有“构造即管理生命周期”的语义。
C++ 更强调 RAII + 控制能力。
五、工程场景 3：try_lock（避免无限阻塞）
std::unique_lock<std::mutex> lock(mtx, std::try_to_lock); if (lock.owns_lock()) { // 拿到锁 } else { // 没拿到锁，做降级处理 }适合场景：
- 日志模块
- 统计模块
- 允许“拿不到锁就算了”的地方
六、为什么条件变量必须用 unique_lock？
下一篇我们讲std::condition_variable。
但提前告诉你：
cv.wait(lock);要求：
lock 必须是 unique_lock
原因：
等待过程会：
- 自动释放锁
- 线程睡眠
- 被唤醒后重新加锁
这需要：
- unlock
- lock
而 lock_guard 做不到。
七、完整示例：更工程化写法
#include <iostream> #include <thread> #include <queue> #include <mutex> std::queue<int> q; std::mutex mtx; void worker() { while (true) { std::unique_lock<std::mutex> lock(mtx); if (q.empty()) { return; } int value = q.front(); q.pop(); lock.unlock(); // 释放锁 std::cout << "Processing: " << value << std::endl; } } int main() { { std::lock_guard<std::mutex> lock(mtx); for (int i = 0; i < 10; ++i) { q.push(i); } } std::thread t1(worker); std::thread t2(worker); t1.join(); t2.join(); }注意：
- 访问队列必须在锁内
- 处理任务在锁外
这就是：
锁保护资源，不保护业务逻辑
八、死锁控制能力（进阶思维）
C++ 允许这样写：
std::unique_lock<std::mutex> lock1(m1, std::defer_lock); std::unique_lock<std::mutex> lock2(m2, std::defer_lock); std::lock(lock1, lock2);std::lock会避免死锁。
这是：
工程级多锁安全方式
Java 对比：
Java 必须手动设计锁顺序。
九、系统取向思维升级
现在你脑子里要形成分层：
第一层：线程模型
谁共享数据？
第二层：资源保护
用 mutex + RAII
第三层：工程控制
什么时候释放锁？
是否允许 try？
是否存在死锁风险？
十、本篇总结
一句话：
lock_guard 是“安全默认”
unique_lock 是“工程控制”
再浓缩一句：
能不用 unique_lock 就不用
需要控制时果断用
下一篇预告（真正进入协作模型）
std::condition_variable —— 线程间通信的正确姿势
- 为什么不能 while 自旋
- 为什么必须用 predicate
- 什么是假唤醒
- 如何写一个 BlockingQueue（生产者消费者）
