std::thread 构造后必须 join 或 detach，否则析构时调用 std::terminate 导致程序直接退出；传参需注意值传递默认拷贝，引用须用 std::ref；共享数据必须同步，避免 data race。
std::thread 构造后必须 detach 或 join，否则程序崩溃
构造 std::thread 对象后，如果它仍处于“可加入”（joinable）状态，而你没调用 join() 或 detach() 就让它析构，C++ 标准强制调用 std::terminate() —— 程序直接退出，不抛异常，也不打印堆栈。
常见错误现象：terminate called without an active exception，尤其在函数返回、局部 thread 变量离开作用域时悄无声息挂掉。
- 永远在
std::thread对象生命周期结束前决定它的归属：要么t.join()等它结束，要么t.detach()放它独立运行 - 推荐优先用
join()，除非你明确需要后台线程且能确保资源不会提前释放（比如线程只访问全局或静态对象） - 可以用 RAII 封装：写个简单的
scoped_thread类，在析构里自动join()，避免遗漏
传递参数给 std::thread 时，值传递是默认行为，引用需显式包装
std::thread 构造函数对参数做完美转发，但**不是按你写的字面意思传参**。比如你写 std::thread(f, x)，x 是左值，会被拷贝；想传引用？必须用 std::ref(x)，否则线程里拿到的是副本，改了也影响不到主线程变量。
使用场景：多个线程要协作更新同一个容器、计数器或配置对象。
立即学习“C++免费学习笔记（深入）”；
- 传原始指针安全，但你要自己管好生命周期（别在线程还在用时 delete）
- 传
std::ref(x)时，确保x的生存期长于线程执行时间，否则就是悬垂引用 - 传 lambda 捕获时同理：用
[&x]是引用捕获，但若 x 是局部变量，线程可能访问已销毁的栈内存
共享数据不加锁就读写，结果不可预测，不是“偶尔出错”而是“必然未定义”
没有同步机制下，多个线程同时读写同一块内存（比如一个 int counter），编译器可能重排指令、CPU 可能缓存不一致、写操作可能非原子——最终值既不是 0 也不是 1000，可能是任意中间态，甚至触发硬件异常（极少见但可能）。
性能影响：std::mutex 加锁开销不大，但争抢激烈时会阻塞；std::atomic 对简单类型（int、指针）更轻量，但不能用于复合操作（如“读-改-写”需 fetch_add）。
- 别用
volatile替代同步：它只禁用编译器优化，不管 CPU 缓存和重排 - 避免锁粒度太粗：比如整个函数只用一把全局 mutex，会严重串行化
- 优先考虑无锁结构（如
std::atomic）或读写分离（std::shared_mutex），但前提是逻辑真能拆开
线程局部存储（thread_local）解决“每个线程一份副本”需求，但注意初始化时机
thread_local 变量每个线程独有一份，首次访问时才构造，线程退出时自动析构。适合缓存、上下文、随机数引擎等无需跨线程共享的状态。
容易踩的坑：如果变量是类类型，它的构造函数在线程中首次访问时才调，而不是线程启动时；若构造抛异常，该次访问失败，后续再访问还会重试构造——可能反复崩溃。
- POD 类型（如
thread_local int x = 42;）安全，零成本初始化 - 类类型建议用惰性初始化模式：声明为指针 +
static thread_local T* p = nullptr;，首次访问时 new 一次 - 不要在
thread_local对象的析构函数里调用可能依赖其他线程资源的代码，析构顺序不确定
多线程里最麻烦的从来不是怎么启线程，而是谁在什么时候访问哪块内存、访问时那块内存到底是什么状态。哪怕只差一行锁、一个 std::ref、一次忘记 join，结果都可能从“功能正常”跳到“偶发崩溃”，而且很难复现。
