C++11中两个独立临界区是否可使用嵌套lock_guard？

关于Q1：分设两个独立mutex的设计合理性 #

这种设计是完全合理的，属于细粒度锁控制的常规实践：

• 当两个临界区保护的共享数据完全独立（不存在需要保证原子性的组合状态变更需求）时，为其分别配置独立mutex，比使用单个全局大锁的并发效率高得多，能大幅减少不必要的锁竞争，避免操作其中一份数据时，另一份无关数据的访问线程被无意义阻塞。
• 唯一需要遵守的规则：如果后续出现需要同时访问两份共享数据的逻辑，必须在所有代码路径中严格固定加锁顺序（例如永远先锁mut_a再锁mut_b），避免循环等待导致死锁。如果所有逻辑都和你当前的需求一样，同一时间最多持有一把锁，就完全不存在死锁风险。

关于Q2：示例代码的规范性与线程安全性 #

首先要明确：你写的代码语法合法，不会出现共享数据的并发访问问题，但和你预期的加锁逻辑不一致，存在潜在风险，核心原因是你对C++17 if初始化语句的作用域理解有偏差：
if (init-statement; condition) 语法中，init-statement里声明的变量生命周期覆盖整个if-else结构，也就是说你在if后初始化的lock_guard<mutex> lck(mut_a)会一直持有mut_a的锁，直到整个if-else块（包括else分支的全部逻辑）执行完毕才会析构释放。

你当前代码的实际执行流是：

1. 加锁mut_a
2. 判断a的值：如果为真，执行if块内的a处理逻辑，执行完成后释放mut_a
3. 如果a为假，不会释放mut_a，直接持有mut_a的锁进入else分支，再加锁mut_b，执行b的处理逻辑，等else块全部执行完后，才会先后释放mut_b、mut_a

这种写法的问题：

• 平白扩大了mut_a的锁持有范围，访问b的时候无意义持有mut_a的锁，会不必要地阻塞其他需要访问a的线程，损失性能
• 如果项目中其他代码路径存在先锁mut_b再锁mut_a的逻辑，会直接触发死锁

如果你的预期逻辑是：先锁mut_a检查a，a成立就处理a后释放锁；a不成立就先释放mut_a，再加锁mut_b检查处理b，需要手动给第一个锁加作用域限制生命周期，修正后的代码如下：

bool need_handle_a = false;
// 单独作用域控制mut_a的生命周期
{
    lock_guard<mutex> lck(mut_a);
    need_handle_a = a;
    if (need_handle_a) {
        // 执行a相关处理逻辑
    }
}
// 出了上面的作用域，mut_a已经完全释放，再处理b的分支
if (!need_handle_a) {
    lock_guard<mutex> lck(mut_b);
    if (b) {
        // 执行b相关处理逻辑
    }
}

修正后，代码完全符合C++并发编程规范，能保证线程安全，也符合你最初设计细粒度锁的性能预期。

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