std::mutex不可拷贝因底层OS原语无值语义，C++显式删除拷贝操作；lock_guard轻量且RAII确定，unique_lock灵活但有开销；多锁死锁须用scoped_lock统一顺序；atomic仅适用于简单原子操作，复杂同步仍需mutex。
std::mutex 为什么不能拷贝，只能移动或引用？
因为 std::mutex 底层封装了操作系统原语（如 pthread_mutex_t 或 CRITICAL_SECTION），这些资源不具备值语义——复制一份锁对象毫无意义，还可能引发未定义行为。C++ 明确删除了拷贝构造和拷贝赋值操作符。
常见错误现象：error: use of deleted function ‘std::mutex::mutex(const std::mutex&)’，通常出现在把 std::mutex 成员放进容器（如 std::vector<:mutex></:mutex>）或试图传值传递时。
- 正确做法：用
std::vector<:unique_ptr>></:unique_ptr>或直接在类中声明为成员，通过引用/指针共享 - 若需多个线程共用同一把锁，就传
std::mutex&；若每个数据项配一把锁，建议用std::array<:mutex n></:mutex>或动态分配 - 不要尝试用
std::shared_ptr<:mutex></:mutex>来“共享所有权”——锁本身不需要共享所有权，只需要共享引用
std::lock_guard 和 std::unique_lock 的核心区别在哪？
std::lock_guard 是最轻量的 RAII 封装，构造即加锁、析构即解锁，不支持延迟加锁、不可转移、不可手动解锁；std::unique_lock 更灵活，但有轻微运行时开销（内部维护一个是否已锁定的状态标志）。
使用场景决定选型：只做简单临界区保护，无条件优先用 std::lock_guard；需要条件等待（配合 std::condition_variable）、分段加锁、或函数内部分支才加锁时，必须用 std::unique_lock。
立即学习“C++免费学习笔记（深入）”；
-
std::lock_guard构造后无法调用unlock()，也不接受std::defer_lock等标记 -
std::unique_lock可以：调用unlock()提前释放、调用lock()再次加锁、支持try_lock_for()等超时操作 - 性能影响：在高竞争、高频短临界区场景下，
std::lock_guard的确定性析构更易被编译器优化，而std::unique_lock多一次分支判断
多个 mutex 加锁顺序不当导致死锁，怎么破？
两个线程分别按不同顺序请求两把锁（比如线程 A 先锁 mtx_a 再锁 mtx_b，线程 B 反之），就极易触发死锁。这不是概率问题，是必然可复现的竞争路径。
根本解法不是“加 try_lock 避免阻塞”，而是统一加锁顺序 + 使用 std::scoped_lock（C++17 起）或 std::lock（C++11 起）。
-
std::scoped_lock<code>mtx_a,mtx_b> 在构造时原子性地获取所有锁，内部自动按地址升序加锁，避免死锁 - 不要手写
mtx_a.lock(); mtx_b.lock();—— 即使加了if (!mtx_a.try_lock())，也无法彻底规避竞态窗口 - 若锁来自不同模块，难以约定地址顺序，应改用“锁粒度合并”策略：用单个
std::mutex保护多个相关数据，或引入读写锁std::shared_mutex（C++17）降低冲突频率
std::atomic 能替代 mutex 吗？什么时候会失效？
可以替代——但仅限于对单一布尔变量的读写同步，且不涉及其他内存操作的依赖关系。一旦出现“检查-执行”逻辑（如 if (flag) do_something();），或需保证多变量间一致性，std::atomic 就不够用了。
典型失效场景：std::atomic<bool></bool> 标记任务完成，但任务结果存于普通变量中；此时读取 flag 为 true 后，读取结果变量仍可能看到旧值——缺少 memory_order 的正确约束，或没用 std::atomic_thread_fence。
- 安全用法：纯状态标志（如
running = false）、自旋等待（while (!ready.load(std::memory_order_acquire))） - 危险用法：把
std::atomic<bool></bool>当作“轻量 mutex”去保护一段代码块，尤其当块内含非原子变量读写时 - 容易忽略的点：默认
load()/store()是std::memory_order_seq_cst，看似安全，但性能损耗大；实际中常需降级为acquire/release配对，否则编译器或 CPU 重排仍可能破坏逻辑
std::mutex 成员变量被无意暴露给外部，或者在 lambda 捕获中隐式延长了锁的作用域，都比语法错误更难调试。 
