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