在析构函数中获取mutex锁是否为不良设计？附RAII并发场景

你的担忧完全不是过度紧张——析构函数里获取锁确实存在明显的设计隐患，主要体现在以下两点：

• 死锁风险：析构函数常被自动触发（比如对象出作用域、异常栈展开时），如果当前线程已持有其他锁，或其他线程持有该锁同时等待当前线程的锁，极易触发死锁，且排查难度远高于主动调用的函数。
• 异常安全问题：虽然lock_guard构造不会抛异常，但push_back可能因内存分配失败抛出异常。C++中析构函数抛出未捕获异常会直接导致程序终止，属于未定义行为。

更优的RAII实现方案：职责分离+封装同步逻辑 #

核心思路是让Foo完全负责自身数据的线程安全操作，Bar仅专注于资源的持有与自动归还，无需直接处理锁：

#include <vector>
#include <mutex>
#include <stdexcept>
#include <iostream>

class Foo {
private:
    std::vector<int> nums;
    std::mutex foo_mtx; // 避免用lock作为变量名，防止和std::lock冲突
public:
    // 封装安全的资源获取逻辑
    int take_last() {
        std::lock_guard<std::mutex> guard(foo_mtx);
        if (nums.empty()) {
            throw std::runtime_error("No available elements in Foo");
        }
        int num = nums.back();
        nums.pop_back();
        return num;
    }

    // 封装安全的资源归还逻辑
    void give_back(int num) {
        std::lock_guard<std::mutex> guard(foo_mtx);
        nums.push_back(num);
    }
};

class Bar {
private:
    Foo& m_foo;
    int m_num;
public:
    Bar(Foo& foo) : m_foo(foo), m_num(m_foo.take_last()) {}

    // 标记析构为noexcept，确保异常不会传播
    ~Bar() noexcept {
        try {
            m_foo.give_back(m_num);
        } catch (...) {
            // 仅做日志记录，禁止重新抛出异常
            std::cerr << "Failed to return element: " << m_num << std::endl;
        }
    }
};

方案优势 #

1. 职责清晰：Foo管同步和数据，Bar管资源生命周期，符合单一职责原则。
2. 异常可控：析构函数内捕获所有异常，避免因资源归还失败导致程序崩溃。
3. 封装性强：Bar无需知晓Foo的内部实现细节，后续修改Foo的存储结构（比如换用队列）不会影响Bar的逻辑。
4. 命名规范：避免了lock这类和标准库重名的变量，消除潜在编译冲突。

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