std::mutex仅提供排他访问机制，真正保护数据需将共享访问严格限定在加锁后、解锁前的临界区；必须用lock/unlock或RAII（如std::lock_guard）显式包裹，否则仍会导致数据竞争或死锁。
std::mutex 本身不“保护”数据，它只提供排他访问机制；真正起保护作用的是你把共享数据的访问逻辑严格限定在加锁之后、解锁之前的代码段里。
临界区必须显式用 lock/unlock 或 RAII 封装
很多人误以为只要声明了 std::mutex，变量就自动线程安全了。不是这样。临界区（即访问共享数据的那段代码）必须被明确包裹在锁的控制之下：
- 手动方式：调用
mtx.lock()后才能读写共享变量，操作完必须调用mtx.unlock() - RAII 方式：用
std::lock_guard<std::mutex>或std::unique_lock<std::mutex>构造时自动加锁，离开作用域自动解锁 - 漏掉任一环节（比如忘了
unlock()，或在异常路径中跳过），临界区就失效，可能引发死锁或数据竞争
std::lock_guard 是最常用也最安全的临界区封装方式
std::lock_guard 的设计目标就是“绝不让你忘记解锁”。它构造时调用 mtx.lock()，析构时无条件调用 mtx.unlock()，哪怕函数中途抛异常也不会跳过析构。
- 必须按值传递（不能取地址或 move），否则会提前析构导致提前解锁
- 作用域要精确覆盖整个临界区，比如不要把
std::lock_guard声明在函数开头却只在结尾才访问数据 - 不能用于需要延迟加锁、多次加锁/解锁、或跨作用域转移锁所有权的场景——这时得换
std::unique_lock
示例：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
std::mutex mtx;
int shared_counter = 0;
void safe_increment() {
std::lock_guard<std::mutex> guard(mtx); // ✅ 加锁在此处发生
++shared_counter; // ✅ 临界区开始
// 即使这里 throw std::runtime_error("oops"); 也能保证解锁
} // ✅ guard 析构，自动 unlock()
临界区范围过大或过小都会出问题
临界区不是越长越好，也不是越短越安全——它必须恰好包含所有对共享数据的读写操作，且不包含可并行的非共享逻辑。
- 范围过大：比如在锁内做耗时 I/O、网络请求、或调用可能阻塞的第三方函数，会严重拖慢其他线程
- 范围过小：比如只锁了
++shared_counter，但后续还有依赖该值的判断逻辑（如if (shared_counter > 100) notify();），那这个判断就可能读到脏值 - 多个共享变量需共用同一把锁：不能为每个变量配一个
std::mutex就认为安全了，若它们语义上有关联（比如 balance 和 account_status），必须用同一把锁保护整个逻辑单元
std::mutex 类型选错会导致隐性崩溃
std::mutex 是最基础类型，但它不支持递归加锁。如果同一线程在未释放锁的情况下再次调用 lock()，行为是未定义的（常见表现是进程卡死）。
- 递归场景（比如函数 A 加锁后调用函数 B，B 也要访问同一资源）：改用
std::recursive_mutex - 需要超时等待锁（避免无限阻塞）：用
std::timed_mutex配合try_lock_for() - 读多写少（如配置缓存）：C++17 起可用
std::shared_mutex，允许多个读线程并发，但写线程独占 - 所有这些类型都不能混用：
std::lock_guard<std::timed_mutex>是合法的，但std::lock_guard<std::mutex>无法用于std::timed_mutex对象
最容易被忽略的一点是：锁的生命周期必须长于所有可能访问它的线程。全局 std::mutex 最稳妥；局部对象或动态分配的 mutex 如果在某个线程还在用它时就被销毁，会导致未定义行为——这种 crash 往往难以复现，但一旦发生几乎无法调试。
