std::mutex是C++中不可递归、不可拷贝的同步原语，需配合std::lock_guard或std::unique_lock使用；单独调用lock/unlock易致死锁或未定义行为，多锁应按地址顺序加锁（推荐std::scoped_lock），且须确保其生命周期覆盖所有访问。
std::mutex 是什么？不是锁，是锁的载体
它本身不“锁住”任何东西，只是个同步原语，配合 std::lock_guard 或 std::unique_lock 才能生效。单独调用 mtx.lock() 而不配对 mtx.unlock()，或者在异常路径下漏掉解锁，立刻埋下死锁或未定义行为的种子。
常见错误现象：std::system_error: Resource deadlock avoided —— 这不是警告，是 Linux 内核直接拒绝了你对同一个 std::mutex 的重复加锁（递归锁），而 C++ 标准 mutex 默认不支持递归。
- 别手写
lock()/unlock()配对：99% 的场景该用std::lock_guard - 需要延迟加锁、条件判断或手动释放？才考虑
std::unique_lock，但得明确管理生命周期 - 不要跨线程传递已加锁的
std::mutex对象——它不可拷贝、不可移动，传指针或引用也极危险
多个 mutex 怎么按顺序加锁才不卡死？
死锁最常发生在两个线程以不同顺序请求同一组 mutex：线程 A 先锁 mtx_a 再等 mtx_b，线程 B 反过来。解决核心就一条：所有代码路径必须按**全局一致的地址顺序**获取锁。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::scoped_lock（C++17 起）：它自动按地址升序加锁，且异常安全。例如std::scoped_lock lk(mtx_a, mtx_b);比手写mtx_a.lock(); mtx_b.lock();安全得多 - 没 C++17？用
std::lock(mtx_a, mtx_b)+std::lock_guard组合，避免手写顺序逻辑 - 绝对不要依赖变量声明顺序、函数参数顺序或“我觉得先锁 A 更合理”这种直觉——只有内存地址可比、可复现
std::mutex 和 std::recursive_mutex 什么时候该选谁？
绝大多数时候选 std::mutex；std::recursive_mutex 是特例，不是补救措施。
使用场景差异：
-
std::mutex：保护共享数据结构（如队列、map）、临界区短且逻辑清晰。性能略好，占用内存更小，暴露设计缺陷更早 -
std::recursive_mutex：仅当函数可能被自身重入调用，且无法重构（比如某些回调接口、旧代码胶水层）。它掩盖了锁粒度混乱和调用栈失控的问题 - 注意：
std::recursive_mutex在 Windows 上开销明显更大；Linux 下 pthread_mutex_t 默认也不支持递归，得显式设 flag
为什么 unlock() 之后还 crash？常见内存问题
mutex 本身不管理数据生命周期。最容易被忽略的是：锁保护的是“访问”，不是“存在”。std::mutex 对象被析构后，再调用其 lock() 或 unlock() 就是未定义行为——哪怕看起来“刚 unlock 完”。
典型踩坑点：
- 局部
std::mutex成员，在对象析构中途被其他线程调用成员函数并尝试加锁 - shared_ptr 管理的资源里含
std::mutex，但 weak_ptr 升级失败后仍盲目调用 lock() - 把
std::mutex放在 malloc 分配的裸内存里，没调用构造函数（std::mutex不是 trivially constructible）
简单验证方式：在 mutex 析构前加日志，确认所有线程确实已退出临界区且不再持有其引用。
