C++多线程开发中的锁嵌套问题。锁嵌套指的是同一个线程多次获取同一个锁（重入）的情况。在C++中，标准库提供了不同的锁类型和策略来处理这种情况。
我们可以总结以下几种处理方式：
1. 使用递归互斥锁（recursive_mutex）：递归互斥锁允许同一个线程多次获得同一个锁，每次加锁都需要对应次数的解锁。这是最直接的解决方案。
2. 重构代码，避免嵌套加锁：通过重新设计类的接口，确保在同一个线程中不会出现对同一个锁的多次请求。例如，将需要加锁的公共部分提取为私有函数，并确保公有函数在调用时不会出现嵌套加锁的情况。
3. 使用分层锁（Hierarchical Locking）：这是一种设计模式，通过规定锁的层次顺序来避免死锁，同时也可以避免嵌套加锁的问题。但这种方法需要预先设计锁的层次结构。
4. 使用RAII（Resource Acquisition Is Initialization）包装器：如std::lock_guard和std::unique_lock，它们可以确保锁在作用域退出时被释放，避免由于异常导致的死锁。虽然RAII本身不解决递归加锁，但可以结合递归互斥锁使用。

下面分别用代码示例说明这些方法：

方法1：使用递归互斥锁（std::recursive_mutex）
当同一个线程可能多次进入同一个锁的保护区域时（例如，一个公共函数调用了另一个公共函数，而这两个函数都需要加锁），递归互斥锁可以避免死锁。
使用std::recursive_mutex，同一个线程可以多次加锁。
允许同一线程多次获取同一锁，内部通过计数机制实现。

 #include <iostream>
#include <thread>
#include <mutex>

class SafeCounter {
public:
    void increment() {
        std::lock_guard<std::recursive_mutex> lock(rec_mtx); // 递归锁
        call_nested(); // 嵌套调用
    }

    void call_nested() {
        std::lock_guard<std::recursive_mutex> lock(rec_mtx); // 同一线程可重入
        count++;
        std::cout << "Count: " << count << std::endl;
    }

private:
    int count = 0;
    std::recursive_mutex rec_mtx; // 递归锁声明
};

int main() {
    SafeCounter counter;
    std::thread t1([&] { counter.increment(); });
    t1.join();  // 输出: Count: 1 （无死锁）
}

优点：简单直接，解决嵌套调用问题
缺点：性能略低于普通互斥锁

方法2：重构代码，避免嵌套加锁
我们可以将需要加锁的公共函数拆分为两部分：一个公共函数负责加锁并调用一个私有函数，该私有函数执行实际操作而不加锁（因为已经由公共函数加锁）。这样，即使一个公共函数调用另一个公共函数，也不会出现同一个线程多次请求同一个锁的情况。
我们将需要嵌套调用的函数拆分为带锁的公共函数和不带锁的私有函数。
另外，我们还会提到RAII包装器的使用，因为手动管理锁的解锁容易出错，尤其是在有异常的情况下。我们通常使用std::lock_guard或std::unique_lock（具有RAII特性）来管理锁。
提取无需重复加锁的内部方法，确保锁只获取一次：
下面给出具体代码：

 class Motor {
public:
    void api_1() {
        std::lock_guard<std::mutex> lock(mtx); // 外层加锁
        // ... 其他操作
        api_2_locked(); // 调用无锁版本
    }

    void api_2() {
        std::lock_guard<std::mutex> lock(mtx); // 独立调用时加锁
        api_2_locked();
    }

private:
    void api_2_locked() { // 私有方法，假设调用时已持有锁
        // 无需加锁的操作
        std::cout << "Critical operation" << std::endl;
    }
    
    std::mutex mtx; // 普通非递归锁
};

优点：避免递归锁开销，逻辑更清晰
缺点：需重构接口，调用方需注意锁状态

方法3：分层锁设计（Hierarchical Locking）
（在提供的搜索结果中没有直接示例，但根据描述，它主要是通过锁的层次顺序来避免死锁，并不直接解决递归加锁问题。因此，我们重点讨论前两种方法。）
强制定义锁的获取顺序，预防死锁：

 class HierarchicalLock {
public:
    explicit HierarchicalLock(int level) : current_level(level) {
        if (prev_level >= current_level) 
            throw std::logic_error("Lock hierarchy violated");
        prev_level = current_level;
    }

    ~HierarchicalLock() {
        prev_level = 0; // 解锁时重置层级
    }

    static thread_local int prev_level; // 线程局部存储记录上次层级
private:
    int current_level;
};

thread_local int HierarchicalLock::prev_level = 0;

void high_level_op() {
    HierarchicalLock lock1(1000); // 高层级锁
    // ... 操作
}

void low_level_op() {
    HierarchicalLock lock2(500);  // 低层级锁
    // high_level_op(); // 此处调用将抛出异常（层级违规）
}

优点：彻底预防死锁
缺点：设计复杂，需规划全局锁层级

选择建议

关键原则：
• 优先用普通锁 + 接口重构（性能最佳）
• 递归锁作为备选方案
• 始终使用RAII管理锁（如lock_guard），避免手动lock/unlock