线程安全需精准识别共享数据并合理同步，锁粒度要细、顺序要固定、生命周期要匹配，死锁是设计缺陷而非偶然，detach线程易致资源泄漏。
线程安全 ≠ 加个锁就完事，死锁也从来不是“运气差”才触发——它只在你忽略资源获取顺序、混用锁粒度或忽视线程生命周期时必然出现。
识别共享数据：栈上变量不加锁，堆/全局/静态变量必须保护
每个线程的栈是私有的，int local = 0、std::vector<int> v</int>（未被多线程共享）这类局部对象天然线程安全；但一旦变量出现在以下位置，就必须考虑同步：
-
static int count或int* p = new int(0)—— 全局、静态、堆内存，所有线程可见 - 类的非 const 成员变量被多个线程通过不同对象实例访问（如单例、全局服务对象）
- 函数参数传入的是指针或引用，且该地址在其他线程中也被使用
错误示例：count++ 看似简单，实际拆成 load-add-save 三步，任何一步被抢占都会导致结果丢失。别信“它只是个整数”，要看它在哪分配、被谁访问。
synchronized / std::mutex 的正确用法：锁粒度要细，作用域要明确
Java 中用 synchronized(locker)、C++ 中用 std::lock_guard<:mutex></:mutex>，核心不是“有没有锁”，而是“锁住了什么、多久、谁在等”：
- 避免对整个循环加锁（如把
for整体包进synchronized），这等于废掉并发——只锁真正共享修改的那行，比如仅count++ - 锁对象必须是稳定、唯一、生命周期长于线程的；别用临时对象、局部变量地址或
this（除非确认该对象不会被多线程同时传入不同锁上下文） - C++ 中
std::mutex不可拷贝、不可移动，必须显式声明为成员或全局静态，别试图把它塞进std::vector或作为 lambda 捕获值传递
常见坑：synchronized(this) 在继承场景下可能意外暴露锁对象；std::mutex m; 声明在栈上却跨线程使用，导致未定义行为。
避免死锁：按固定顺序获取锁，绝不嵌套等待同一组资源
死锁不是偶发 bug，是设计缺陷的必然结果。只要两个线程以相反顺序请求两把锁，比如：
- 线程 A：先 lock(
mutex_a) → 再 try_lock(mutex_b) - 线程 B：先 lock(
mutex_b) → 再 try_lock(mutex_a)
就已埋下死锁种子。解决方案只有两个硬规则：
- 所有代码路径中，对多个互斥量的获取顺序必须全局一致（例如始终按地址升序：if (
&m1 ) { lock(m1); lock(m2); }） - 禁用嵌套同步块——不要在一个
synchronized块里调另一个需要不同锁的方法，更不要递归调用自身加锁方法 - 用
std::scoped_lock（C++17）或tryLock+ 回退逻辑替代手写双重 lock，它能原子性地获取多个锁并自动规避死锁
注意：std::lock 和 std::scoped_lock 是少数几个能安全处理多锁的工具，别自己造轮子。
detach 线程与资源泄漏：不 join 就 detach 是最危险的简化
t.detach() 不是“让线程自己跑”，而是把线程和当前作用域彻底解绑——它可能还在访问局部变量、已析构的对象、或已关闭的文件句柄：
- 主线程退出后，detached 线程若尝试写
std::cout或访问main函数栈上的std::string，行为未定义 - 没
join也没detach的线程对象在析构时会直接std::terminate()，程序崩溃 - 正确做法：用
std::jthread（C++20）自动管理生命周期，或确保join被调用（哪怕放在 RAII 类的析构中）
最容易被忽略的一点：即使你用了 std::shared_ptr 管理资源，也不能保证 detached 线程不会在 shared_ptr 析构后继续解引用——因为线程调度无法被你精确控制。
