C++多线程线程安全核心是明确共享资源边界、选对同步机制、控制临界区范围；std::mutex适用于多线程读写同一非原子内存，std::atomic仅适用于简单类型单点操作，std::lock_guard通过RAII确保自动加解锁，避免异常导致死锁，构造中传递this指针会导致未定义行为。
直接说结论：C++ 多线程并发下保证线程安全，核心不是“加锁就行”，而是「明确共享资源边界 + 选对同步机制 + 控制临界区范围」。盲目套用 std::mutex 可能掩盖问题，甚至引入死锁或性能瓶颈。
什么时候必须用 std::mutex？
当多个线程会同时读写同一块非原子内存时，std::mutex 是最直接、最可控的方案。典型场景包括：
- 修改全局变量、静态成员变量或类内共享成员（如
std::list、std::vector） - 实现线程安全容器（如带锁的队列、缓存）
- 临界区内含多步逻辑（比如先查再删、先判空再 pop），不能被原子操作覆盖
注意：std::mutex 本身不保护数据，它只保护你用它包裹的那段代码逻辑。漏锁、重复锁、跨作用域持有锁，都会失效。
std::atomic 能替代锁吗？
可以，但仅限于简单类型和单点操作。比如计数器递增、标志位切换、指针交换等。
立即学习“C++免费学习笔记（深入）”；
-
std::atomic<int></int>的++是原子的，但if (x > 0) x--;不是——这需要两步判断+修改，仍得用std::mutex或std::atomic的 CAS 循环 -
std::atomic对std::string、std::vector等复合类型无效；它们的线程安全必须靠外部同步 - 性能上，
std::atomic通常比锁快，但频繁 CAS 会引发总线争用，反而拖慢
为什么 std::lock_guard 比手动 lock()/unlock() 更可靠？
因为异常或提前 return 会让手动解锁极易遗漏，导致死锁。而 std::lock_guard 是 RAII 实现：
- 构造即加锁，析构即解锁，不依赖代码路径
- 不能转移所有权（无 move 构造），杜绝误传、误拷贝
- 如果需要延迟锁定、条件等待或与
std::condition_variable配合，才换用std::unique_lock
常见错误：在函数开头 mtx.lock()，中间 throw 异常，结尾没走到 mtx.unlock() —— 这种写法在生产环境等于埋雷。
最容易被忽略的坑：对象生命周期与 this 指针泄漏
线程安全不只是锁数据，更是锁住“谁在什么时候能访问什么”。构造函数中把 this 传给其他线程，是最隐蔽的线程不安全来源：
- 对象尚未构造完成，其他线程就可能调用其成员函数，读到未初始化的字段
- 即使加了锁，也无法防止构造中途被访问——锁在对象初始化之后才生效
- 正确做法是：用工厂函数创建对象，确认构造完毕后再启动线程，或用
std::shared_ptr+ 初始化标记控制可见性
这类问题不会报错，也不会崩溃，但结果随机、复现困难，调试成本极高。
