std::thread析构前必须join()或detach()，否则调用std::terminate()终止程序；join()同步等待并回收资源，detach()移交所有权后线程独立运行，但需确保其访问的数据生命周期足够长。
std::thread::join() 必须调用，否则程序直接终止
std::thread 对象析构时，如果仍处于 joinable() 状态，C++ 标准强制调用 std::terminate() —— 不是报错、不是警告，而是立即杀进程。这不是异常，无法捕获，也绕不开。
常见错误现象：
- 局部
std::thread对象在函数末尾自动析构，但忘了join()或detach() - 提前 return 或 throw 导致跳过
join()调用点 - 多个分支路径中只在一个分支调用了
join()
实操建议：
- 始终在调用
join()前检查t.joinable()，避免对已join或已detach的线程重复操作 - 用 RAII 封装：比如写个
scoped_join类，在构造时接受std::thread&，析构时自动join() - 不要在
join()前加条件判断（如“只有调试时才 join”），这会让 release 版本悄悄崩溃
std::thread::detach() 后线程与对象完全解耦
detach() 不是“后台运行”的快捷键，而是移交所有权：线程继续执行，但 std::thread 对象不再代表它，也不能再控制它。此时 t.joinable() 返回 false，再调 t.join() 会抛 std::system_error 异常。
立即学习“C++免费学习笔记（深入）”；
容易踩的坑：
- detach 后访问主线程栈上的变量：子线程可能还在跑，但主线程函数已退出，局部变量早已销毁 → 野指针或读取垃圾内存
- detach 的线程里用了
this指针，而宿主对象已被 delete → 典型 use-after-free - 误以为 detach 后能“随时取消”：不能。detach 后线程不可控，只能等它自己结束
使用场景有限：
- 日志刷盘线程（生命周期与整个进程一致）
- 心跳上报（不依赖外部状态，纯靠内部计时器）
- 确实不需要同步、也不关心结果的 fire-and-forget 任务
join 和 detach 的资源回收机制不同
join() 是由调用方线程负责回收资源：包括线程栈、内核线程描述符等；detach() 则由 C++ runtime 在线程真正退出后自动回收。
关键差异：
- 没
join()的线程对象析构 → 立即std::terminate() - 没
join()但已detach()的线程对象析构 → 安全，无副作用 - 已
join()的线程对象再次join()→ 抛异常 - 已
detach()的线程对象再join()→ 抛异常 - 线程已自然结束，但还没
join()→joinable()仍为true，join()会立刻返回
性能影响很小，但语义差别极大：前者是同步等待+资源清理，后者是放生+托管回收。
别用 detach 处理带引用/指针参数的线程
这是最隐蔽也最危险的用法。例如：std::thread t(func, &local_var) 然后马上 detach() —— local_var 在函数返回后就失效了，但子线程可能几毫秒后才真正开始读它。
正确做法只有两种：
- 用
join()，确保生命周期覆盖整个执行过程 - 把数据拷贝进线程（如传值、
std::shared_ptr、或在线程内 new 内存）
哪怕你加了 sleep(1) 测试看似没问题，那也只是运气好。优化等级一变、CPU 负载一高，bug 就浮现。
复杂点在于：detach 后的线程是否安全，完全取决于它内部所有数据的生命周期是否独立于创建它的作用域 —— 这个判断没法靠编译器检查，只能靠人审。
