std::jthread 析构时自动 join() 并内置 stop_token 支持协作式中断；要求线程函数首参为 std::stop_token 才能自动注入，否则退化为自动 join，C++20 起可用且仅支持移动。
析构时自动调用 join()，不用再怕 std::terminate()
用 std::thread 时，只要对象析构前没调 join() 或 detach()，程序立刻调 std::terminate() —— 这不是报错，是直接崩，而且常发生在异常路径或提前 return 时，极难复现。
std::jthread 把这事包圆了：析构时自动 join()，等线程跑完才销毁自己。你写 std::jthread t(task);，哪怕中间抛异常、函数提前返回、或者就忘了写 t.join()，它都安全收尾。
- 不用手动加
try/catch去保join() - RAII 真正落地：构造即启动，析构即等待
- 和
std::thread接口几乎一致，迁移成本极低
带内置 std::stop_token，支持协作式中断
std::thread 没有标准中断机制，常见做法是自己搞个 std::atomic 标志位轮询，但无法通知线程“立刻停在某个安全点”，更没法注册清理回调。
std::jthread 构造时自带一个 std::stop_source，你可以用 t.get_stop_token() 获取对应 std::stop_token，还能通过 t.request_stop() 外部触发停止请求。
立即学习“C++免费学习笔记（深入）”；
- 线程函数若接受
std::stop_token为首个参数，jthread会自动传入（无需手动提取） - 必须在线程内部主动检查
stoken.stop_requested()，不能只靠外部调用request_stop() - 可注册
std::stop_callback做资源清理，比如关闭文件、释放锁、取消 pending I/O
#include#include void worker(std::stop_token stoken) { while (!stoken.stop_requested()) { std::cout << "working...\n"; std::this_thread::sleep_for(100ms); } std::cout << "cleaning up and exit\n"; }
int main() { std::jthread t(worker); std::this_thread::sleep_for(300ms); t.request_stop(); // 发出停止请求 // 析构时自动 join，无需再等 }
参数签名差异：能自动传递 stop_token，但必须显式声明
std::jthread 不会“偷偷”把 stop_token 塞进任意函数；它只在可调用对象**第一个参数类型是 std::stop_token** 时，才自动注入。其他参数照常传递。
- 写
[](std::stop_token stoken, int x) { ... }✅ 可以 - 写
[](int x, std::stop_token stoken) { ... }❌ 不会自动传，stoken会是默认构造的空 token - 不带
std::stop_token参数？没问题，退化为普通自动join行为，和std::thread+ RAII 封装效果类似
兼容性与性能开销：C++20 起可用，轻量但不可忽略
std::jthread 是 C++20 新增类型，编译器需开启 -std=c++20（GCC/Clang）或 /std:c++20（MSVC）。它内部多持有一个 std::stop_source，内存开销约十几个字节，无锁设计，运行时检查 stop_requested() 是原子读，开销极小。
- 旧项目升级：只需替换
std::thread为std::jthread，并按需加stop_token参数 - 不能复制，只能移动 —— 和
std::thread保持一致 - 没有
detach()方法：设计上就不鼓励分离线程，强制你面对生命周期问题
真正容易被忽略的，是协作中断的“协作”二字：它不终止线程，只发信号；线程不检查 stop_token，就永远收不到——这不像信号处理，而是靠你写进循环条件、I/O 等待点、甚至 std::condition_variable::wait 的 predicate 里。漏掉一次检查，就可能卡住整个退出流程。
