直接裸调用 std::mutex::lock() 和 unlock() 极易因异常、提前 return 或分支遗漏导致锁未释放而死锁；raii（如 std::lock_guard）通过作用域绑定确保析构时必解锁，是安全首选。
为什么直接用 std::mutex::lock() 和 unlock() 很危险
手动配对调用 lock() 和 unlock() 极易出错：异常抛出、提前 return、逻辑分支遗漏都会导致锁未释放，引发死锁或资源竞争。RAII 的核心价值不是“看起来优雅”，而是让锁的生命周期严格绑定到作用域——只要对象析构，锁就必然释放。
实操建议：
- 永远不要裸用
std::mutex::lock()；哪怕只有一行临界区代码，也必须用 RAII 封装 - 避免在构造函数里传入已加锁的 mutex（
std::defer_lock是例外，见下一条） - 注意：
std::mutex本身不可拷贝、不可移动，所有 RAII 类都只持引用或指针
std::lock_guard 是最常用且最安全的选择
它在构造时自动加锁，析构时自动解锁，不支持延迟加锁或手动解锁，语义最简单明确，适合绝大多数“进作用域即加锁”的场景。
示例：
std::mutex mtx;
void safe_update() {
std::lock_guard<:mutex> guard(mtx); // 构造即 lock()
shared_data++; // 临界区
} // guard 析构 → unlock() 自动执行</:mutex>
常见错误：
- 把
guard声明成指针（new std::lock_guard<...>(mtx)</...>）→ 析构不触发，锁永不释放 - 跨作用域传递
std::lock_guard对象 → 编译失败（移动/拷贝被禁用），这是设计保护，别绕过 - 在
if分支内声明 → 锁范围比预期小，容易漏保护
需要延迟加锁或手动控制时，用 std::unique_lock
std::unique_lock 比 lock_guard 更灵活：支持延迟构造、转移所有权、条件变量配合、手动 lock()/unlock()。但灵活性带来责任——你得自己确保最终会析构。
典型用法：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 延迟加锁：
std::unique_lock<:mutex> lk(mtx, std::defer_lock);</:mutex>→ 后续按需调lk.lock() - 配合
std::condition_variable：cv.wait(lk, []{ return ready; });→ 等待期间自动解锁，唤醒后自动重锁 - 提前释放锁：
lk.unlock();→ 后续可再lk.lock()或让其析构时不重复解锁
性能提示：相比 lock_guard，unique_lock 有轻微运行时开销（内部多一个布尔标记），无必要不替换。
多个互斥锁同时获取？必须用 std::lock 防死锁
顺序加锁（先锁 A 再锁 B）在多线程下极易因执行时序不同导致 AB-BA 死锁。C++ 标准库提供原子化加锁机制。
正确做法：
- 用
std::lock(mtx_a, mtx_b)一次性尝试获取多个锁（内部使用类似银行家算法的策略） - 再用
std::lock_guard或std::unique_lock的带std::adopt_lock参数构造，表示“锁已持有，别再 lock”
示例：
std::mutex mtx_a, mtx_b;
void transfer() {
std::lock(mtx_a, mtx_b); // 原子化获取两把锁
std::lock_guard<:mutex> ga(mtx_a, std::adopt_lock);
std::lock_guard<:mutex> gb(mtx_b, std::adopt_lock);
// 安全操作
}</:mutex></:mutex>
关键点：不用 std::adopt_lock 而直接传 mutex 给 lock_guard，会导致二次加锁 → 未定义行为（通常 crash 或死锁）。
真正容易被忽略的是：RAII 只解决“锁是否释放”，不解决“锁粒度是否合理”。过度细化（每行都套 guard）或过度粗放（整个函数一把锁）都会损害并发性能。锁的边界要和业务语义对齐，而不是由 RAII 的便利性决定。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
