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()，而不是依赖异常（异常机制只用于“通知+清理”，不是主控制流）：
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
<ul>
<li>
<code>std::stop_callback</code> 构造即注册，析构自动注销；不能跨线程移动或复制</li>
<li>回调函数必须 <code>noexcept</code>，且不能阻塞太久（它运行在调用 <code>request_stop()</code> 的上下文中）</li>
<li>不要在回调里调用 <code>join()</code> 或等待其他线程——这会造成死锁</li>
</ul>
<h3>std::jthread 与 std::thread 在中断语义上的关键差异</h3>
<p><code>std::jthread</code> 不是 <code>std::thread</code> 的增强版，而是全新语义模型：它自带 stop_source、自动 join、RAII 生命周期管理。混用两者容易出错。</p>
<ul>
<li>不能对 <code>std::jthread</code> 对象调用 <code>detach()</code> —— 编译报错：<code>std::jthread</code> 禁止分离</li>
<li>
<code>std::thread</code> 没有 stop_token，强行模拟协作中断需手动传入 <code>std::atomic<bool>&</bool></code>，易遗漏检查或竞态</li>
<li>从 <code>std::jthread</code> 获取 <code>stop_source</code> 只能通过成员函数 <code>get_stop_source()</code>，不能像 <code>std::stop_source</code> 那样自由复制（其拷贝是独立的）</li>
<li>如果线程函数签名不含 <code>std::stop_token</code> 参数，<code>std::jthread</code> 会传入一个无效 token（<code>stop_possible() == false</code>），此时 <code>stop_requested()</code> 永远返回 false</li>
</ul>
<p>协作式中断真正起作用的地方，从来不在“怎么发 stop”，而在于“线程体里有没有真正看 stop”。漏掉一次轮询，就可能让线程挂住几秒甚至永久。别指望编译器或运行时帮你补上。</p></bool>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
