std::unique_lock 提供比 std::lock_guard 更灵活的锁控制，支持延迟加锁（std::defer_lock）、手动加解锁、配合条件变量 wait 使用及通过移动语义传递锁所有权，适用于需精细控制互斥量的场景。
在C++11中，std::unique_lock 是一个比 std::lock_guard 更灵活的锁管理工具，它允许你更精细地控制互斥量（mutex）的加锁和解锁时机。使用 std::unique_lock 可以实现“可控锁”，即根据条件决定是否加锁、延迟加锁、手动释放锁等。
延迟加锁与手动控制加锁状态
std::unique_lock 支持构造时不立即加锁，通过指定参数 std::defer_lock 实现延迟加锁：
- 构造时传入 std::defer_lock，不会对 mutex 加锁
- 之后可调用 lock() 手动加锁
- 也可调用 unlock() 提前释放锁
示例代码：
#include <mutex>
#include <iostream>
std::mutex mtx;
void controlled_lock_example() {
std::unique_lock<std::mutex> lock(mtx, std::defer_lock); // 不加锁
// 做一些不需要锁的操作
std::cout << "Doing work before locking...\n";
// 根据条件决定是否加锁
bool need_lock = true;
if (need_lock) {
lock.lock(); // 手动加锁
std::cout << "Locked and accessing shared resource.\n";
// 访问临界区
}
// 可以手动提前释放锁
if (lock.owns_lock()) {
lock.unlock();
std::cout << "Lock released early.\n";
}
// 此后可重新加锁，或让其在析构时自动处理
}
配合条件变量使用
std::unique_lock 常用于配合 std::condition_variable，因为条件变量的 wait() 方法要求传入一个 unique_lock：
立即学习“C++免费学习笔记（深入）”；
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
std::mutex mtx;
std::condition_variable cv;
bool ready = false;
void waits_for_data() {
std::unique_lock<std::mutex> lock(mtx);
cv.wait(lock, []{ return ready; }); // wait 会自动释放锁，并在唤醒后重新获取
std::cout << "Data is ready, continuing...\n";
}
void sets_data_ready() {
std::unique_lock<std::mutex> lock(mtx);
ready = true;
cv.notify_one();
}
这里 wait() 内部会临时释放锁，避免阻塞其他线程，唤醒后再重新获取锁，这只有 unique_lock 能做到。
支持移动语义传递锁所有权
std::unique_lock 可以转移锁的所有权，适用于需要在函数间传递锁的场景：
std::unique_lock<std::mutex> acquire_lock_if_needed(std::mutex& mtx, bool should_lock) {
std::unique_lock<std::mutex> lock(mtx, std::defer_lock);
if (should_lock) {
lock.lock();
}
return lock; // 移动返回，转移锁的所有权
}
// 使用示例
std::mutex mtx;
auto lock = acquire_lock_if_needed(mtx, true);
if (lock.owns_lock()) {
std::cout << "We own the lock.\n";
}
这种机制让你可以在不同作用域之间安全地传递锁的持有状态。
基本上就这些。相比 std::lock_guard，std::unique_lock 提供了更多控制能力：延迟加锁、手动解锁、配合条件变量、转移所有权。只要你不追求极致性能（它比 lock_guard 稍慢一点），在需要“可控锁”的场景下，它是首选。
