jthread在C++20中析构时自动join，无需手动检查joinable；但若线程访问已销毁对象、提前释放jthread或构造失败仍会崩溃；需配合stop_token协作退出，且线程函数必须主动轮询stop_requested()。
jthread 在 C++20 中自带自动汇合（join）行为，只要它持有活跃线程，析构时就会调用 join() —— 这是它和 std::thread 最关键的区别。不需要手动写 if (t.joinable()) t.join();，也不用靠 RAII 封装一层；它本身就是 RAII 的。
为什么不用手动 join，但有时仍会 crash？
常见错误是在线程函数里访问了已销毁的对象，比如捕获了局部变量的引用、或 this 指针指向栈对象，而 jthread 的自动汇合只保证“等线程结束”，不保证“线程安全地结束”。
- 若线程函数中用了
[&]捕获局部变量，对象生命周期早于线程结束 → 未定义行为 - 若在线程运行中提前释放了
jthread对象（如 vector::clear、作用域提前退出），而线程还在跑 →jthread析构会阻塞等待，但资源可能已不可用 -
jthread构造失败（如系统资源不足）时抛出std::system_error，不是静默失败
如何正确配合 stop_token 实现协作式退出？
jthread 内置 std::stop_source，可通过 get_stop_token() 获取 std::stop_token，再传给线程函数做轮询退出判断。注意：这不是抢占式中断，必须在线程函数里主动检查。
jthread t([](std::stop_token st) {
while (!st.stop_requested()) {
// 做工作...
std::this_thread::sleep_for(100ms);
}
// 清理逻辑（可选）
});
- 必须显式把
std::stop_token作为首个参数传入线程函数，否则无法接收通知 -
st.stop_requested()是轻量级无锁调用，可高频轮询；但不要在 tight loop 里空转，加 sleep 或 wait 保持响应性 - 调用
t.request_stop()后，st.stop_requested()立即返回 true，但线程是否退出取决于你何时检查
request_stop() 调用时机与线程状态的隐含依赖
request_stop() 是线程安全的，可在任意时刻从任意线程调用，但它本身不阻塞、不等待、不保证线程已退出。真正的汇合仍在 jthread 析构时发生。
立即学习“C++免费学习笔记（深入）”；
- 若想“触发退出 + 等待完成”，应先
t.request_stop()，再让t自然离开作用域（或显式移动赋值为jthread{}） - 不能对已析构的
jthread调用request_stop()，会抛std::system_error（error_code ==std::errc::operation_not_permitted） - 若线程函数未使用
stop_token，request_stop()仍成功，但线程不会响应 —— 这是常见静默失效点
真正容易被忽略的是：协作式退出的有效性完全取决于线程函数里是否及时响应 stop_token，而不是 jthread 本身有多“智能”。自动汇合只是兜底机制，不是退出逻辑的替代品。
