std::lock_guard能自动加锁解锁因其构造时调用lock()、析构时调用unlock()，践行RAII原则；正确使用需确保其作用域严格覆盖临界区，且不可手动unlock或跨分支声明。
std::lock_guard 为什么能自动加锁解锁
因为它的构造函数会立即调用 mutex.lock()，析构函数（对象生命周期结束时）自动调用 mutex.unlock()——这正是 RAII 的核心：资源获取即初始化，资源释放即析构。不需要手动配对调用，哪怕中间抛异常，析构也照常执行。
常见错误是试图“提前解锁”或“重复解锁”，比如在作用域内显式调用 mutex.unlock()，结果导致析构时再次 unlock，触发未定义行为（通常是程序崩溃或 std::terminate）。
使用场景很明确：只要需要保护一段临界区代码，且该段代码执行时间可控、不涉及跨函数移交锁所有权，std::lock_guard 就是最直接的选择。
如何正确声明和作用域控制 lock_guard
必须让 std::lock_guard 对象的生命期严格覆盖整个临界区。它不能是局部变量但被提前 return 绕过，也不能放在 if 分支里导致部分路径没加锁。
立即学习“C++免费学习笔记（深入）”；
- ✅ 正确：在临界区起始处声明，作用域用大括号限定
- ❌ 错误：声明在函数开头但临界区只占后半段（锁持有时间过长）
- ❌ 错误：放在
if (cond) { std::lock_guard<:mutex> lk(mtx); /* ... */ }</:mutex>里——锁只在 if 分支生效，else 分支无保护
示例：
void safe_increment() {
{
std::lock_guard<std::mutex> lk(mtx); // 临界区从这里开始
counter++;
} // 析构发生在这里，自动 unlock
do_something_else(); // 不在锁保护下
}lock_guard 和 unique_lock 的关键区别在哪
二者都支持 RAII，但 std::lock_guard 是“一次性不可转移”的：构造即加锁，析构即解锁，不提供 unlock() 或 lock() 方法，也不能转移所有权。
std::unique_lock 更灵活，支持延迟加锁（std::defer_lock）、手动解锁再加锁、条件变量配合、以及移动语义。但灵活性带来额外开销（内部多一个布尔标志位）和误用风险。
所以：
- 只读/写一小段固定代码 → 用
std::lock_guard - 需要条件等待（
std::condition_variable::wait）→ 必须用std::unique_lock - 要实现“先试锁，失败就做别的事” → 用
std::unique_lock配合try_to_lock
别为了“以后可能扩展”而默认选 unique_lock——多数临界区不需要那层抽象。
容易忽略的线程安全陷阱
std::lock_guard 只保证对同一 std::mutex 实例的串行访问，但它不解决以下问题：
- 多个互不相关的 mutex 保护不同数据，但逻辑上需同时操作 → 可能死锁（应统一用
std::lock多锁） - 锁住的是局部变量或临时对象 → 实际没保护任何共享状态
- 共享对象本身是
const，但内部有可变成员（如mutable std::mutex）→ 必须确保所有访问路径都经过锁，包括 const 成员函数 - 误用
std::recursive_mutex当普通 mutex 用 → 性能差，且掩盖了本该避免的递归调用设计
最常被跳过的一步：确认你锁的真的是那个被多线程读写的变量——而不是它的副本、指针副本，或者另一个同名但不同实例的 mutex。
