std::mutex必须配合RAII锁管理器使用，推荐std::lock_guard（轻量、自动析构）或std::unique_lock（支持try/timeout/手动unlock）；多锁需固定顺序防死锁，优先用C++17的std::scoped_lock；禁止裸调lock/unlock、重复加锁、拷贝赋值，注意mutable修饰及静态初始化线程安全。
std::mutex 必须配合 std::lock_guard 或 std::unique_lock 使用
直接调用 mutex.lock() 和 mutex.unlock() 极易出错——忘记 unlock、异常中途跳出、提前 return，都会导致死锁。C++ 标准库不鼓励裸调用，而是靠 RAII 自动管理生命周期。
正确做法是把锁包装进作用域：只要 std::lock_guard 对象存在，互斥就生效；离开作用域自动释放。它轻量、无延迟、不可手动释放，适合绝大多数临界区。
-
std::lock_guard<:mutex></:mutex>是最简选择，构造即加锁，析构即解锁，不支持转移、不支持尝试加锁、不支持超时 - 需要 try_lock 或超时？改用
std::unique_lock<:mutex></:mutex>，但它稍重，且必须显式unlock()才能提前释放（否则仍靠析构） - 永远不要在同一个线程里对同一个
std::mutex重复调用lock()—— 这不是可重入锁，会死锁
多个 mutex 加锁顺序不一致 → 死锁高发区
当一段逻辑要同时操作两个共享对象（比如转账：从 A 扣款 + 给 B 加款），就得锁两个 std::mutex。如果线程 1 先锁 A 再锁 B，线程 2 偏偏先锁 B 再锁 A，就卡住了。
标准解法是固定全局加锁顺序，例如按对象地址排序：
立即学习“C++免费学习笔记（深入）”；
if (&mutex_a < &mutex_b) {
std::lock_guard<std::mutex> lock1(mutex_a);
std::lock_guard<std::mutex> lock2(mutex_b);
} else {
std::lock_guard<std::mutex> lock1(mutex_b);
std::lock_guard<std::mutex> lock2(mutex_a);
}
- 更简洁的方式是用
std::scoped_lock（C++17 起），它自动按地址顺序加多个锁，且异常安全：std::scoped_lock lock(mutex_a, mutex_b); - 避免跨函数传
std::mutex*并在不同地方随意加锁——逻辑分散后顺序极易失控 - 调试时若程序卡住不动，优先检查是否有多 mutex 场景且没统一顺序
std::mutex 不可拷贝、不可移动，别存 vector 或作为类成员乱初始化
std::mutex 禁止拷贝和赋值，编译器会直接报错。常见误用是想动态创建一堆带锁的对象，写成 std::vector<std::mutex> 或在类里写 std::mutex mtx = std::mutex(); —— 后者调用默认构造没问题，但赋值那行非法。
- 要管理多个 mutex？用
std::vector<std::unique_ptr<std::mutex>>或直接std::vector<std::mutex>（C++11 起允许默认构造的容器，但不能 push_back 未构造的 mutex） - 类中声明
mutable std::mutex mtx;是常见模式（尤其用于缓存等只读接口里的写操作），注意加mutable否则 const 成员函数里无法调用mtx.lock() - 全局或静态
std::mutex安全，但局部静态 mutex（如函数内static std::mutex m;）在首次调用时才构造，线程安全由编译器保证（C++11 起）
std::mutex 阻塞式、无超时、不响应中断，替代方案要看场景
std::mutex 的 lock() 会一直等下去，没有“等 10ms 失败就走”的能力。如果你需要非阻塞或带超时的同步，它就不合适。
- 想试试看能不能抢到锁？用
std::unique_lock::try_lock()，返回 bool - 要等一段时间？用
std::unique_lock::try_lock_for()或try_lock_until() - 真正需要异步取消或中断等待？
std::mutex做不到，得换std::condition_variable配合，或上平台级原语（如 pthread_mutex_timedlock） - 性能敏感且临界区极短？考虑
std::atomic_flag手写自旋锁，但注意别空转太久耗 CPU
mutex 的设计目标就是简单可靠，不是灵活多变。用错场景时，问题往往不出在“怎么写”，而出在“该不该用它”。
