正确使用 std::mutex 需固定加锁顺序、避免嵌套调用、优先用 std::scoped_lock，仅保护真正并发读写的非原子数据，注意 shared_mutex 适用场景及 lock_guard 必须为栈对象。
std::mutex 怎么用才不会死锁
加锁不是套个 std::lock_guard 就完事，常见死锁发生在多个 mutex 按不同顺序加锁时。比如线程 A 先锁 mtx_a 再锁 mtx_b，线程 B 反过来先锁 mtx_b 再锁 mtx_a，两线程卡住互等。
实操建议：
- 所有需要同时操作的共享资源，统一按固定地址顺序加锁（例如比较
&mtx_a ，总是先锁地址小的那个） - 避免在持有锁期间调用可能间接加锁的函数（如虚函数、回调、第三方库接口）
- 优先用
std::scoped_lock而非多个std::lock_guard：它能自动按安全顺序加多个锁，且异常安全 - 调试时开启
-D_GLIBCXX_DEBUG（libstdc++）或使用 TSan（ThreadSanitizer），能捕获部分锁序问题
哪些数据必须用 mutex 保护
不是所有变量都需要锁——只有被多个线程**并发读写**的非原子对象才真正需要。只读共享数据（如配置字符串）通常不用锁；std::atomic 类型的计数器也不需要额外 mutex。
容易踩的坑：
立即学习“C++免费学习笔记（深入）”；
-
std::vector的push_back()和size()不是原子操作，多线程增删查必须整体包裹在同一个std::mutex下 - 看似“只读”的结构体，如果其成员指针指向的数据会被其他线程修改，那这个“读”其实隐含了对目标内存的访问，仍需同步
- STL 容器迭代器失效规则在线程间不成立：一个线程调用
erase()，另一个线程用旧迭代器访问，属于未定义行为，哪怕加了锁也救不了——必须确保访问和修改由同一把锁保护
std::mutex 和 std::shared_mutex 性能差多少
读多写少场景下，std::shared_mutex（C++17）允许并发读，但写操作仍会阻塞所有读写。实测中，纯读吞吐可提升 2–5 倍，但写操作延迟略高，且构造/析构开销更大。
使用条件：
- 读操作远多于写操作（比如缓存查找 vs 缓存更新）
- 读操作本身耗时明显（不能是几个指令就完事的简单计算）
- 编译器支持 C++17 且标准库实现靠谱（MSVC 2019+、GCC 8+、Clang 7+ 较稳；老版本
std::shared_mutex可能退化为独占锁） - 注意
std::shared_lock和std::unique_lock的语义区别：前者允许多个共存，后者排他，混用时别错用类型
为什么 lock_guard 析构没释放锁
典型现象是程序 hang 在某个 std::mutex::lock() 调用上，而你以为前面的 std::lock_guard 已经自动解锁了。根本原因通常是：该 lock_guard 对象生命周期提前结束（比如被 return 或异常中断），或者你误用了指针或静态对象导致析构时机失控。
排查要点：
- 确认
std::lock_guard是栈上对象，不是new出来的指针（堆对象不会自动析构） - 检查作用域是否被意外截断（比如 if 分支里声明，但逻辑跑到了 else）
- 若函数有多个
return，确保每个出口前都已进入锁的作用域，或改用 RAII 更稳妥的写法 - 不要手动调用
mtx.unlock()—— 这会破坏 RAII，且和lock_guard析构冲突，引发未定义行为
线程安全的本质不是“加了锁就万事大吉”，而是明确每块内存的访问契约：谁读、谁写、何时可见、是否允许并发。mutex 只是履行契约的工具之一，用错地方比不用还危险。
