C++互斥锁使用教程：多线程同步技巧

std::mutex必须配合RAII类（如std::lock_guard或std::unique_lock）使用，裸调lock()/unlock()易因异常、提前return等导致死锁；多锁需统一顺序或用std::scoped_lock避免AB-BA死锁；mutex不可复制移动，应为private成员并禁用拷贝；递归需求才用std::recursive_mutex；关键在合理界定共享数据与临界区粒度。

std::mutex 必须配合 std::lock_guard 或 std::unique_lock 使用

直接调用 mutex.lock() 和 mutex.unlock() 极易出错——忘记 unlock、提前 return、抛异常都会导致死锁。C++ 标准库不推荐裸调用，而是靠 RAII 自动管理生命周期。

实操建议：

• std::lock_guard 最常用：构造即加锁，析构即解锁，不能转移，轻量且安全
• std::unique_lock 用于需要延迟加锁、手动解锁、或配合条件变量的场景
• 永远不要在同一个线程里对已持有的 std::mutex 再次调用 lock() —— 这是未定义行为，多数实现会死锁

多个 mutex 加锁顺序不一致会引发死锁

两个线程分别按不同顺序获取 mtx_a 和 mtx_b，比如线程1先锁 a 再锁 b，线程2先锁 b 再锁 a，就可能互相等待对方释放——典型 AB-BA 死锁。

实操建议：

• 所有代码路径中，对一组 mutex 的加锁顺序必须严格一致（例如始终按地址大小排序）
• 用 std::scoped_lock（C++17 起）一次性加多个锁，它内部自动按地址排序并避免死锁：std::scoped_lock lock(mtx_a, mtx_b);
• 旧标准可用 std::lock(mtx_a, mtx_b) + std::lock_guard 的组合，但更啰嗦

std::mutex 不可复制、不可移动，别传值或存 vector

常见错误：把 std::mutex 成员变量设为 public，然后意外被拷贝；或试图 std::vector —— 编译直接失败，因为 std::mutex 删除了拷贝和移动构造函数。

实操建议：

• mutex 应作为类的 private 成员，且类本身也应禁用拷贝（显式删除 MyClass(const MyClass&) = delete;）
• 需要 N 个互斥资源？用 std::vector> 或静态数组，而不是直接存对象
• 跨线程共享 mutex？不行——mutex 只能在线程内持有，且不能跨线程传递所有权；它只是同步原语，不是数据载体

递归锁不是默认选项，std::recursive_mutex 要主动选

有些场景确实需要同一线程多次进入临界区（比如递归函数调用），但 std::mutex 不支持。有人误以为“加锁两次就自动递归”，结果程序卡死。

实操建议：

• 明确需要递归语义时，才用 std::recursive_mutex，并配 std::lock_guard 或 std::unique_lock
• 注意性能开销：递归锁内部要维护计数器和持有线程 ID，比普通 std::mutex 重
• 绝大多数业务逻辑不需要递归锁——重新设计函数边界、提取临界区外的公共逻辑，通常比用递归锁更清晰、更安全

真正难的不是写对 lock/unlock，而是判断哪段数据算“共享”、哪个粒度该加锁、以及锁住之后是否还调用了可能阻塞或抛异常的第三方代码——这些地方一漏，std::mutex 就成了幻觉。