std::thread最常踩的坑是析构时仍joinable导致调用std::terminate()终止；std::jthread通过析构时自动join解决该问题，并提供stop_token/stop_source实现协作取消。
std::jthread 出现前，std::thread 最常踩的坑是什么？
不是启动失败，而是忘记 join() 或 detach() —— 一旦 std::thread 对象析构时仍处于可加入（joinable()）状态，程序直接调用 std::terminate() 终止，毫无商量余地。这在异常路径、提前 return、RAII 容器管理线程时特别容易中招。
常见错误现象：std::thread::~thread(): Assertion `!joinable()' failed 或静默崩溃；使用场景多见于构造函数里启线程、lambda 捕获局部变量后在线程里访问、或 try/catch 中线程对象生命周期没兜住。
实操建议：
- 永远在
std::thread构造后立刻决定是join()还是detach()，别拖到作用域末尾 - 避免在线程对象上做条件分支（比如“成功就 join，失败就 detach”），逻辑一复杂就漏掉
- 若需传递取消信号，得自己手写
std::atomic+ 循环检查，没有内置协作机制
std::jthread 怎么自动解决 joinable 析构问题？
它在析构函数里自动调用 join() —— 不是粗暴 detach()，也不是放任不管，而是等线程自然结束。这是它“更安全”的最直接原因：你写错生命周期，它不 crash，而是帮你兜底等待。
立即学习“C++免费学习笔记（深入）”；
但注意：这个行为只在未显式调用 join() 或 detach() 时触发。一旦你手动调用了其中之一，std::jthread 就不再干预，和 std::thread 行为一致。
实操建议：
- 把旧代码里的
std::thread直接替换成std::jthread，能立刻消除析构期terminate()风险 - 不需要改线程函数签名，也不需要加额外参数 —— 它只是加了一层 RAII 包装
- 如果线程本应长期运行（比如后台监控），仍要主动
detach()，否则析构会卡住主线程
std::jthread 的 stop_token 和 stop_source 是干啥的？
这是它比 std::thread 多出的核心协作取消能力：无需自己定义原子变量、无需约定检查频率，标准库提供了一套轻量、无锁、一次性的通知机制。
stop_token 交给线程函数，用来查询是否被请求停止；stop_source 留在主线程，调用 request_stop() 即可发信号。线程内只需在合适位置调用 token.stop_requested() 或阻塞等待 token.wait()。
实操建议：
- 线程函数参数里加一个
std::stop_token token，这是唯一需要改的地方 - 避免在 tight loop 里高频轮询
stop_requested()，可用std::this_thread::sleep_for()或带超时的wait_until()降低开销 -
stop_token是可拷贝的，适合传给多个子任务共享同一个取消源 - 注意：
std::jthread构造时自动关联自己的stop_source，不用手动 new
什么时候不该用 std::jthread？
不是所有场景都适合。它比 std::thread 多一点开销（内部多一个 stop_source 和关联逻辑），也多一点约束（比如不支持 move-only 的 callable，因需复制 stop_token）。
性能/兼容性影响：
- C++20 起才有，老项目升级编译器前不能用
- 某些嵌入式或实时环境禁用异常或 RTTI，而
std::jthread的析构 join 可能抛std::system_error（虽然概率低） - 如果线程必须绝对“火速 detach 并消失”，
std::jthread的自动 join 反而是负担，此时宁可用裸std::thread+detach()
最容易被忽略的一点：它的“安全”只覆盖析构和协作取消两个维度。资源竞争、数据竞态、死锁、栈溢出……这些该你操心的，它一个都不会管。
