程序会卡死，线程永久阻塞在后续lock()调用上；std::mutex不支持递归加锁且无自动释放机制，必须用RAII（如std::lock_guard或std::unique_lock）确保异常安全的自动加解锁。
std::mutex加锁后不释放会怎样
程序卡死，线程永久阻塞在后续的 lock() 调用上。C++ 的 std::mutex 不支持递归加锁，也不带超时或自动释放机制——它就是一把“纯手动机械锁”。一旦忘记解锁（比如函数提前 return、抛异常），其他线程就永远等不到这把锁。
所以不能裸写 mutex.lock() 和 mutex.unlock()；必须靠 RAII 自动管理生命周期：
- 优先用
std::lock_guard：构造即加锁，析构即解锁，适用于作用域内完整保护 - 需要延迟加锁、手动控制加锁时机，或尝试加锁时，改用
std::unique_lock
std::lock_guard 最简安全用法
这是 95% 场景该选的方式。它轻量、无状态、不可转移，编译期就能防止误用：
std::mutex mtx;
int shared_data = 0;
<p>void increment() {
std::lock_guard<std::mutex> lock(mtx); // 构造即 lock()
++shared_data; // 访问临界区
} // 析构自动 unlock() —— 即使这里 throw 异常也保证执行
注意：std::lock_guard 不提供 unlock() 方法，也不允许拷贝，只支持移动（但通常没必要移动）；传参时别写成 std::lock_guard<:mutex>(mtx)</:mutex>——那会被解析为函数声明（最令人头疼的 C++ 括号歧义）。
立即学习“C++免费学习笔记（深入）”；
什么时候非用 std::unique_lock 不可
三种典型场景：std::unique_lock 支持延迟加锁、条件变量配合、以及手动释放再加锁（比如长耗时操作中短暂放开锁）：
- 和
std::condition_variable配合时，必须用std::unique_lock（std::lock_guard不满足接口要求） - 需要先加锁、做部分工作、临时解锁让其他线程推进、再重新加锁 —— 用
unlock()和lock() - 尝试加锁不阻塞：
if (auto lk = std::unique_lock{mtx, std::try_to_lock}) { /* 成功 */ }
代价是稍重一点（内部有布尔状态记录是否已持有锁），且容易误用：手动 unlock() 后忘了再 lock()，或者重复 lock() 导致未定义行为。
常见错误：全局/静态 mutex 初始化顺序问题
如果在多个翻译单元里定义了静态 std::mutex，又在全局对象构造函数中访问它，可能触发静态初始化顺序惨案——某个 mutex 还没构造完成就被调用了 lock()，结果是未定义行为（常见表现：程序启动就 crash 或 hang 在 pthread_mutex_lock）。
稳妥做法只有两个：
- 把
std::mutex变成局部静态变量（C++11 起保证首次访问时线程安全初始化）：static std::mutex& get_mutex() { static std::mutex m; return m; } - 或直接放在函数内部作为局部变量（如果逻辑允许）
别依赖全局对象的构造顺序，也别在 main() 之前做任何带锁操作。
