std::jthread 是什么，为什么比 std::thread 更安全
std::jthread 是 C++20 引入的线程类，本质是 std::thread 的“可自动连接（joinable）且可协作中断”的封装。它在析构时**自动调用 join()**（除非已显式调用 detach()），避免了 std::thread 析构前未 join() 或 detach() 导致的 std::terminate() 崩溃。
更重要的是，std::jthread 内置 std::stop_token 和 std::stop_source，支持标准、轻量、可组合的协作式中断协议——不是强制杀线程，而是通知“该停了”，由线程自己决定何时检查并退出。
如何正确启动一个可中断的 jthread
构造 std::jthread 时，函数对象需能接收一个 std::stop_token 参数（可选）。若不需中断逻辑，可忽略；若需要响应中断，必须显式声明并使用它。
- 函数签名必须匹配：第一个参数为
std::stop_token，后续才是你自己的参数 - 不能只靠
std::this_thread::sleep_for()等阻塞函数自动响应中断——它们本身不检查 token；必须主动调用stop_token.stop_requested()或使用std::condition_variable::wait(..., stop_token)等感知中断的等待函数 - lambda 捕获需注意生命周期：若捕获局部变量并在线程中访问，确保其存活时间长于线程执行期
std::jthread t([](std::stop_token stoken) {
while (!stoken.stop_requested()) {
std::this_thread::sleep_for(100ms);
// 实际工作...
}
// 自动在析构时 join()
});
手动触发中断：stop_source 与 stop_token 的配合
每个 std::jthread 内部持有一个 std::stop_source，可通过 t.get_stop_source() 获取。调用其 request_stop() 即发起中断请求，所有关联的 std::stop_token 都会立即变为 “已请求停止” 状态。
立即学习“C++免费学习笔记（深入）”；
-
std::stop_token::stop_requested()是轻量级轮询，无锁、无同步开销 - 不要在循环中高频调用
request_stop()多次——多次调用等效于一次，但无意义 - 若线程正在阻塞（如
std::condition_variable::wait），需传入stop_token才能被唤醒；否则只能等下一次轮询 -
std::jthread的析构不会自动触发request_stop()，它只负责join()；中断需显式发起
// 主动中断
t.request_stop(); // 等价于 t.get_stop_source().request_stop()
// 在线程内响应
if (stoken.stop_requested()) {
break; // 退出循环
}
常见陷阱：detach()、移动语义与跨作用域中断
std::jthread 支持移动，但移动后原对象变为不可 joinable 状态；而 detach() 会放弃所有权，使 std::jthread 不再管理该线程生命周期——此时析构不再 join()，也不再持有有效的 stop_source。
- 调用
t.detach()后，t.get_stop_source()返回的stop_source无效，request_stop()无效果 - 把
std::jthread存入容器（如std::vector<:jthread>）时，移动构造/赋值是安全的，但需确保容器生命周期长于线程运行时间 - 若线程函数通过引用捕获外部
std::stop_token（而非用std::jthread自带的），则中断机制失效——必须用同一个stop_source发起请求 - Windows 上部分旧版 MSVC（如 19.29 及更早）对
std::jthread的stop_token实现有 bug，建议升级到 VS 2022 17.5+ 或使用 libc++/GCC 12+
真正关键的不是“怎么写第一行 jthread”，而是“谁负责 request_stop、何时 request_stop、线程里是否真的检查了”。中断不是魔法，它是协作契约——漏掉任意一端，就只剩死等或资源泄漏。
