为何在std::unique_lock中使用defer_lock？相关技术疑问解析

示例代码 #

void fun1(std::mutex &m){
    std::lock_guard<std::mutex> mlock(m);
    //多行代码
}

void fun2(std::mutex &m){
    std::unique_lock<std::mutex,std::defer_lock> mlock(m);
    //多行代码
    mlock.lock();
    //多行代码
}

问题1：为何要使用defer_lock？ #

使用std::defer_lock的核心是为了灵活控制锁的生效时机：

• 可以先执行一些不需要访问共享资源的预处理逻辑，避免过早持有锁导致其他线程阻塞，提升并发效率
• 配合std::lock()工具实现多互斥量的安全批量锁定，避免死锁（比如同时锁定多个互斥量时，用std::lock(lock1, lock2)能保证无死锁的顺序）
• 适配std::condition_variable的使用场景——条件变量需要频繁解锁、重新锁定，std::unique_lock配合defer_lock能轻松实现这种操作

问题2：先获取所有权再执行锁定操作的设计意图是什么？ #

这种设计把锁的管理权和实际锁定动作分开了：

• 拿到所有权意味着std::unique_lock对象会负责互斥量的自动解锁（出作用域时不管是否锁定都会正确处理），彻底避免忘记解锁导致的死锁
• 允许你在锁定前做一些判断，比如检查某个条件是否满足，再决定要不要锁定，减少无意义的锁竞争
• 支持复杂的锁状态切换，比如临时解锁释放资源、之后重新锁定，这是std::lock_guard这种轻量级锁做不到的

问题3：获取所有权与锁定操作是否本质相同？ #

完全是两回事：

• 获取所有权：是让std::unique_lock和目标互斥量绑定，拥有对这个互斥量的管理权限，但此时互斥量还是未锁定状态，其他线程照样能访问它保护的资源
• 锁定操作：是调用lock()方法，让当前线程独占这个互斥量，阻止其他线程进入临界区
  简单说，所有权是“管锁的资格”，锁定是“实际占锁的动作”

问题4：若通过std::unique_lock获取std::mutex的所有权但不锁定，是否仍会面临竞态条件风险？ #

当然会。只要你在未锁定的情况下访问了该互斥量保护的共享资源，就会出现竞态条件。
std::unique_lock只是帮你兜底管理解锁动作，但它不会自动保护临界区——只有调用lock()之后，再操作共享资源，才能避免多个线程同时修改资源导致的错误。如果一直不锁定，和直接操作没加锁的共享资源没有区别。

内容的提问来源于stack exchange，提问作者SameemSh.