std::mutex必须配合RAII锁管理器（如std::lock_guard或std::unique_lock）使用，单独声明无效；它不可拷贝、不可重入，需避免死锁、减少锁粒度，并优先考虑std::atomic替代简单场景。
std::mutex 必须和 std::lock_guard 或 std::unique_lock 配合用
单独声明 std::mutex 没用，它不会自动加锁；不配 RAII 容器（如 std::lock_guard），极易漏解锁、死锁或异常安全问题。
常见错误现象：std::mutex::lock() 后忘了 unlock()，或者在函数中途 return/throw 时跳过解锁；多线程下直接访问共享变量仍出现数据竞争。
- 优先用
std::lock_guard：构造即加锁，析构即释放，简单场景够用 - 需要手动控制解锁时机（比如临界区分段执行）、尝试加锁、或转移所有权时，改用
std::unique_lock - 绝不要对同一个
std::mutex在同一线程重复调用lock()—— 这是未定义行为，std::mutex不可重入
示例：
std::mutex mtx;
int counter = 0;
void increment() {
std::lock_guard<std::mutex> lock(mtx); // 自动加锁/解锁
++counter;
}
std::mutex 不能拷贝，只能移动（且通常不该移动）
你没法把一个 std::mutex 传给另一个函数、塞进容器、或赋值给另一个变量——编译直接报错：use of deleted function ‘std::mutex::mutex(const std::mutex&)’。
使用场景：常作为类成员变量存在，通过引用或指针共享；若需在多个对象间“传递”锁语义，应传递封装了锁的 RAII 对象（如 std::unique_lock），而非 mutex 本身。
立即学习“C++免费学习笔记（深入）”；
- 类中定义
mutable std::mutex mtx_;是常见模式，用于保护 const 成员函数里的共享状态 - 想在线程间“共享”同一把锁？确保所有线程访问的是同一个
std::mutex实例地址，而不是各自副本 - 别试图用
std::shared_ptr<:mutex></:mutex>来“绕过”拷贝限制——这反而增加间接开销，且没解决根本设计问题
避免死锁：按固定顺序获取多个 mutex
当一段逻辑需要同时持有两个或以上 std::mutex（比如交换两个对象的状态），若线程 A 先锁 mtx_a 再锁 mtx_b，而线程 B 反过来操作，就极易死锁。
标准解法是用 std::lock + std::adopt_lock，它能原子性地锁定多个互斥量，内部按地址顺序加锁，规避死锁风险。
- 别手写嵌套
lock()调用，哪怕你觉得“顺序一致”——不同编译器优化或内联可能改变实际执行流 - 用
std::lock(mtx_a, mtx_b)后，再用std::lock_guard带std::adopt_lock标签接管已持有的锁 - 注意：
std::lock可能抛std::system_error（如资源不足），需捕获处理
示例：
std::mutex mtx_a, mtx_b;
void transfer(int& from, int& to, int amount) {
std::lock(mtx_a, mtx_b); // 原子锁定两者
std::lock_guard<std::mutex> lock_a(mtx_a, std::defer_lock);
std::lock_guard<std::mutex> lock_b(mtx_b, std::defer_lock);
// 实际更推荐：std::scoped_lock (C++17)，一行搞定
}
std::mutex 性能开销小但不可忽略，别锁太宽或太频
std::mutex 在无竞争时是纯用户态操作（futex 级别），很快；但一旦发生争抢，就会陷入内核、触发上下文切换，延迟陡增——从纳秒级跳到微秒甚至毫秒级。
容易踩的坑：把整个函数体包进 std::lock_guard，或者在循环里反复加锁/解锁；还有人用 mutex 保护只读操作（其实只需原子读或 relaxed memory order）。
- 只锁真正共享、可变、且需原子性的那几行代码，越短越好
- 避免在锁内做 I/O、网络调用、或任何可能阻塞的操作
- 高频更新计数器等简单场景，优先考虑
std::atomic，它比 mutex 更轻量、无锁
复杂点在于：锁粒度太细会增加代码维护难度，太粗又扼杀并发收益。这事没有银弹，得结合具体热点和 profile 数据调。
