std::lock_guard一定义就加锁，因其构造时强制调用mutex.lock()实现RAII，确保作用域内自动锁管理，无延迟加锁机制，且不支持默认构造或赋值。
std::lock_guard 为什么一定义就加锁
std::lock_guard 是 RAII（资源获取即初始化）的典型实现：它在构造时调用 mutex.lock()，析构时自动调用 mutex.unlock()。这意味着只要对象还在作用域内，锁就一直持有；一旦离开作用域（比如函数返回、提前 return、异常抛出），析构函数立刻执行，锁被释放。
常见错误是试图“延迟加锁”或手动控制加锁时机——但 std::lock_guard 不支持。它必须在构造时拿到锁，否则编译失败（因为没有无参构造函数，且不接受已解锁的 mutex）。
- ✅ 正确：
std::mutex mtx;<br>void safe_increment() {<br> std::lock_guard<std::mutex> lock(mtx); // 构造即加锁<br> ++shared_counter;<br>} // 离开作用域，自动 unlock - ❌ 错误：
std::lock_guard<std::mutex> lock; // 编译失败：无默认构造函数<br>lock = std::lock_guard<std::mutex>(mtx); // 编译失败：不可赋值
多个互斥锁怎么避免死锁——用 std::lock + std::lock_guard
当需要同时锁定多个 std::mutex（比如操作两个共享对象），直接顺序调用 lock_guard 构造极易引发死锁：线程 A 先锁 mtx1 再等 mtx2，线程 B 反过来，双方僵持。
标准做法是先用 std::lock(mtx1, mtx2) 原子性地获取所有锁（内部使用避免死锁的算法），再用 std::adopt_lock 告诉 lock_guard “别再自己 lock，我已经锁好了”：
立即学习“C++免费学习笔记（深入）”；
-
std::lock(mtx1, mtx2)成功后，两个 mutex 都已处于锁定状态 -
std::lock_guard的第二个参数必须是std::adopt_lock，否则会重复调用lock()导致未定义行为（可能 crash 或阻塞） - 所有
lock_guard必须按相同顺序声明（比如先mtx1后mtx2），否则破坏 RAII 顺序，可能提前释放某个锁
std::mutex mtx1, mtx2;<br>void transfer_money(Account& from, Account& to, int amount) {<br> std::lock(mtx1, mtx2); // 原子获取两把锁<br> std::lock_guard<std::mutex> guard1(mtx1, std::adopt_lock);<br> std::lock_guard<std::mutex> guard2(mtx2, std::adopt_lock);<br> from.balance -= amount;<br> to.balance += amount;<br>}
std::lock_guard 能不能用于递归锁
不能。标准 std::mutex 不是递归的；同一个线程重复调用 lock() 会导致未定义行为（通常是死锁）。而 std::lock_guard 构造时强制调用 lock()，所以对同一 mutex 多次构造 lock_guard 在同一线程中是危险的。
如果确实需要同一线程多次加锁，应改用 std::recursive_mutex，并配 std::lock_guard<:recursive_mutex></:recursive_mutex>：
-
std::mutex→ 单次锁，轻量，推荐用于绝大多数场景 -
std::recursive_mutex→ 支持同一线程重复 lock/unlock，但有额外开销，且容易掩盖设计问题（比如本该拆分临界区） - 注意：即使用了
recursive_mutex，也不建议在函数内部层层嵌套lock_guard；更应检查是否逻辑可重构
std::recursive_mutex rmtx;<br>void log_with_context() {<br> std::lock_guard<std::recursive_mutex> lock(rmtx); // OK<br> std::cout << "step 1\n";<br> inner_log(); // 内部又用同一个 rmtx 构造 lock_guard<br>}<br>void inner_log() {<br> std::lock_guard<std::recursive_mutex> lock(rmtx); // OK，递归允许<br> std::cout << "step 2\n";<br>}
性能敏感场景下 lock_guard 的开销真能忽略吗
构造/析构 std::lock_guard 本身几乎没有运行时代价（只是存储一个引用 + 调用一次 lock/unlock），真正的开销来自底层系统调用（如 futex 等待）和缓存一致性协议（多核间同步）。
但容易被忽略的是作用域粒度——锁的范围越大，争用越严重，整体吞吐越低。例如下面这种写法看似“安全”，实则扼杀并发：
- ❌ 把整个函数体包进一个
lock_guard，哪怕中间有 IO、计算、网络等待 - ✅ 只包裹真正访问共享数据的几行，其余非共享操作移出临界区
- ⚠️ 特别注意：返回值若依赖共享状态，需在锁内读取并复制出来，再在锁外处理
// ❌ 过度加锁<br>std::string get_status() {<br> std::lock_guard<std::mutex> lock(mtx);<br> auto s = format_status(shared_data); // 耗时格式化<br> sleep_for(100ms); // 绝对不该在锁里 sleep<br> return s;<br>}<br><br>// ✅ 精确临界区<br>std::string get_status() {<br> StatusData local_copy;<br> {<br> std::lock_guard<std::mutex> lock(mtx);<br> local_copy = shared_data; // 仅拷贝，快<br> } // 锁在这里释放<br> return format_status(local_copy); // 格式化和 sleep 都在锁外
实际用的时候，最常翻车的不是语法，而是临界区划得太大、忘了多个锁要统一顺序、或者误以为 lock_guard 能解决所有线程安全问题——它只管“锁住”，不管“逻辑正确”。比如两个原子操作之间仍有竞态，就得靠更高层的设计（如无锁结构、事务性内存，或干脆重构为无共享）。 
