std::mutex必须配合std::lock_guard使用，因其构造即加锁、析构即解锁，确保异常安全；手动lock/unlock易致死锁；多锁需固定顺序或用std::scoped_lock；shared_mutex仅适用于读多写少场景。
std::mutex 必须和 lock_guard 配合用，不能手动 unlock
直接调用 mutex.lock() 后忘了 mutex.unlock()，或者在异常路径里漏掉解锁，程序大概率死锁。C++ 标准库不鼓励手写加锁/解锁逻辑——std::lock_guard 是唯一安全的入门方案。
常见错误现象：std::system_error: Resource deadlock avoided（Linux）或卡死在第二次 lock()；更隐蔽的是只在高并发压测时偶发崩溃。
-
std::mutex本身不可拷贝、不可移动，只能定义为对象成员或局部静态变量 -
std::lock_guard构造即加锁，析构即解锁，哪怕函数中途 throw 异常也保证解锁 - 不要把
lock_guard声明成指针或动态分配——它的生命周期必须和临界区严格对齐 - 示例：正确写法是
std::lock_guard<:mutex> lk(mtx);</:mutex>，不是auto* lk = new std::lock_guard<:mutex>(mtx);</:mutex>
多个 mutex 一起锁时必须固定顺序，否则死锁
两个线程分别按不同顺序获取 mtx_a 和 mtx_b，100% 死锁。这不是 bug，是并发模型本身的约束。
使用场景：比如更新两个关联数据结构（用户余额 + 订单状态），两者各自有独立 mutex。
立即学习“C++免费学习笔记（深入）”；
- 所有代码路径中，必须始终先锁
mtx_a再锁mtx_b（或反之），顺序要全局一致 - 避免嵌套锁：不要在已持有一个 mutex 的函数里，再去调另一个函数，而那个函数又试图获取新 mutex
- C++17 起可用
std::scoped_lock替代多个lock_guard，它自动按地址排序加锁，防止死锁：std::scoped_lock lk(mtx_a, mtx_b); - 注意：
std::scoped_lock不是lock_guard的升级版，它是专为多锁设计的，单锁场景仍用lock_guard
shared_mutex 适合读多写少，但别误用为“性能万能解”
std::shared_mutex（C++17）允许并发读，但写操作仍独占。如果写操作频繁，或读操作本身很重（比如带复杂计算），它反而比普通 mutex 更慢。
性能影响：读锁开销比普通 mutex 高 2–3 倍（涉及原子计数+内存屏障），且部分旧 libc++ 实现不支持，Windows 上需 VS2015u3+。
- 只在确认读操作占比 >90%、且读操作极轻量（纯取值）时才考虑
shared_mutex - 读锁用
std::shared_lock<:shared_mutex></:shared_mutex>，写锁仍用std::unique_lock<:shared_mutex></:shared_mutex>或lock_guard - 别混用：不能用
lock_guard持有shared_mutex的读锁——编译不过，必须用shared_lock - 错误写法：
std::lock_guard<:shared_mutex> lk(mtx);</:shared_mutex>→ 编译报错：no matching constructor
全局或静态 mutex 容易引发初始化顺序问题
在全局作用域或类静态成员里定义 std::mutex，可能在 main() 开始前就被访问（比如静态对象构造函数里调用了加锁逻辑），导致未定义行为。
常见错误现象：程序启动就 crash，堆栈停在 __pthread_mutex_init 或类似底层函数；或者 Linux 下偶尔 core dump，macOS 上看似正常但行为不可靠。
- 解决方案：用局部静态变量延迟初始化，利用 C++11 的“首次访问才构造”语义：
static std::mutex& get_global_mtx() { static std::mutex mtx; return mtx; } - 或者直接用
std::call_once+std::once_flag控制一次初始化 - 绝对不要在头文件里定义非 inline 的全局
mutex，头文件被多个 .cpp 包含会导致 ODR 违规 - 类内静态
mutex成员没问题，但记得在 .cpp 里定义（std::mutex MyClass::s_mtx;）
实际写的时候，最常被忽略的是：mutex 对象的生命周期必须长于所有试图锁它的线程。临时对象、栈上提前销毁的 mutex、被 move 走的 mutex，都会让后续 lock 变成未定义行为。
