std::jthread 的 stop_token 不能直接 kill 线程，因为其设计为协作式中断：线程必须主动轮询 stop_token 或注册回调，否则 request_stop() 无效果；这是为避免资源泄漏、锁未释放等 UB 风险。
std::jthread 的 stop_token 为什么不能直接 kill 线程
std::jthread 不提供强制终止能力，它的中断是协作式的——线程必须主动轮询 stop_token 或注册回调，否则 request_stop() 调用后什么都不会发生。这不是缺陷，而是设计选择：避免资源泄漏、锁未释放、对象析构不完整等 UB 风险。
常见错误是以为调用 jthread.request_stop() 就能立刻停住线程，结果主线程退出而子线程仍在跑，或卡在 std::mutex::lock() 里无法响应中断。
- stop_token 本身不带同步语义，轮询需配合内存序（通常用默认 seq_cst 即可）
- 不能在构造函数、析构函数、
noexcept函数中抛出std::stop_token::stop_requested()异常（C++20 标准禁止） -
std::jthread析构时自动调用request_stop()并join()，但前提是线程体已检查过 token 并退出
如何在循环中安全轮询 stop_token
最典型场景是 while 循环工作线程，需在每次迭代开头或关键阻塞点前检查是否被请求停止。
正确写法是显式调用 stop_token.stop_requested()，而不是依赖异常（异常机制只用于“通知+清理”，不是主控制流）：
立即学习“C++免费学习笔记（深入）”；
std::jthread worker([](std::stop_token stoken) {
while (!stoken.stop_requested()) {
// 执行单位工作（如处理队列一项）
do_work();
// 若此处可能长时间阻塞，应改用可中断等待
// 比如 std::this_thread::sleep_for(...) → 改为 sleep_until + 检查 token
std::this_thread::sleep_for(100ms);
}
// 退出前做必要清理（如 flush buffer、close fd）
cleanup();
});
- 不要把
stop_requested()放在循环末尾——万一do_work()内部耗时很长且不可中断，就无法及时响应 - 避免在 long-running 系统调用（如
read(),accept()）中无检查地等待；应改用超时版本 + token 轮询 - 若使用条件变量，可用
wait_until(..., stoken)替代wait()，它会在 token 触发时自动唤醒
用 stop_callback 实现异步清理和资源释放
当线程正在执行不可中断的系统调用（如 recv()），或需要在中断发生时立即释放某些资源（如取消 pending I/O），std::stop_callback 更合适。
它在 request_stop() 被调用时，由任意线程（通常是发起 stop 的线程）同步执行回调，因此适合做轻量级信号通知或设置原子标志：
std::jthread worker([](std::stop_token stoken) {
std::atomic<bool> should_exit{false};
std::stop_callback cb(stoken, [&]{ should_exit = true; });
while (!should_exit.load(std::memory_order_acquire)) {
int ret = recv(sockfd, buf, sizeof(buf), 0);
if (ret == -1 && errno == EINTR) continue;
if (ret <= 0) break; // 连接关闭或错误
}
});
-
std::stop_callback构造即注册，析构自动注销；不能跨线程移动或复制 - 回调函数必须
noexcept，且不能阻塞太久（它运行在调用request_stop()的上下文中） - 不要在回调里调用
join()或等待其他线程——这会造成死锁
std::jthread 与 std::thread 在中断语义上的关键差异
std::jthread 不是 std::thread 的增强版，而是全新语义模型：它自带 stop_source、自动 join、RAII 生命周期管理。混用两者容易出错。
- 不能对
std::jthread对象调用detach()—— 编译报错：std::jthread禁止分离 -
std::thread没有 stop_token，强行模拟协作中断需手动传入std::atomic<bool>&</bool>，易遗漏检查或竞态 - 从
std::jthread获取stop_source只能通过成员函数get_stop_source()，不能像std::stop_source那样自由复制（其拷贝是独立的） - 如果线程函数签名不含
std::stop_token参数，std::jthread会传入一个无效 token（stop_possible() == false），此时stop_requested()永远返回 false
协作式中断真正起作用的地方，从来不在“怎么发 stop”，而在于“线程体里有没有真正看 stop”。漏掉一次轮询，就可能让线程挂住几秒甚至永久。别指望编译器或运行时帮你补上。
