C++20 stop_token：让线程“听见”停止请求，而不是靠猜

写过多线程代码的人，大概都踩过这个坑：主线程喊“停！”，工作线程却还在埋头跑循环，最后只能粗暴调用 std::thread::join() 等到超时，或者更糟——直接 detach() 任其自生自灭。以前我们靠 bool 标志位 + volatile（其实多数时候没用）+ 心照不宣的内存序提醒，像在薄冰上递纸条。C++20 把这张纸条升级成了带回执的加密信封——std::stop_token。

它不是新线程的启动器，也不是锁的替代品；它是线程间轻量、协作式停止通知的通信凭证。关键在于：它不强制终止，只传递“该考虑收工了”的信号——这恰恰是真实业务中最需要的分寸感。

为什么老办法总让人提心吊胆？

你可能写过这样的循环：

bool should_stop = false;
std::thread t([&]{
    while (!should_stop) {
        do_work();
        std::this_thread::sleep_for(10ms);
    }
});
// …… 某处设置 should_stop = true;
t.join();

问题不在语法，而在语义模糊：should_stop 是谁设的？什么时候可见？如果 do_work() 耗时几秒，线程根本“听不见”信号。更隐蔽的是，编译器可能把 !should_stop 优化成常量判断——除非你加 std::atomic<bool>，但又得操心内存序。这不是写逻辑，是在和编译器与CPU玩捉迷藏。

stop_token 把这套博弈封装进标准库：它背后绑定一个 std::stop_source，所有 stop_token 实例共享同一份停止状态，且读取操作天然具有获取语义（acquire semantics）。你不用记 memory_order_acquire，它已经帮你焊死了。

三步走通：从创建到响应

1. 启动线程时带上“停止凭证”

别再裸传 std::thread，用 std::jthread——它是 std::thread 的智能升级版，自带 stop_source，构造即绑定：

std::jthread worker([](std::stop_token stoken) {
    while (!stoken.stop_requested()) {
        do_work();
        if (stoken.stop_requested()) break; // 双重检查，防漏判
        std::this_thread::sleep_for(10ms);
    }
    cleanup(); // 确保退出前清理资源
});

注意：std::jthread 析构时会自动调用 request_stop() 并 join()，你不需要手动管理生命周期——这是它比裸 std::thread 最实在的减负。

2. 主动请求停止：一次调用，全局生效

想让线程停下？对 jthread 对象调用 request_stop()：

worker.request_stop(); // 一调即生效，无需传参、无需锁

所有通过该 jthread 获取的 stop_token 都立刻感知到状态变更。底层是原子状态机，无竞争风险。

3. 线程内安全响应：别只靠轮询

stop_requested() 是轻量检查，但别让它霸占 CPU。实际场景中，线程常卡在系统调用里（比如 read(), accept()），这时要配合可中断等待：

while (!stoken.stop_requested()) {
    // 使用支持 stop_token 的等待函数（需自行封装或用第三方库）
    // 或退而求其次：用带超时的等待，并在每次超时后检查 token
    if (auto res = wait_with_timeout(100ms); res == timeout) {
        continue;
    } else if (stoken.stop_requested()) {
        break;
    }
}

重点来了：stop_token 不提供阻塞等待接口，但它为“等待-检查”模式提供了确定、廉价的状态查询。这比轮询 atomic<bool> 更可靠，因为它的状态变更与 request_stop() 调用严格同步。

容易被忽略的实战细节

• stop_token 可拷贝，不可移动：它像 std::shared_ptr，拷贝只是增加引用，状态共享。别试图 std::move 它——编译不过。
• std::jthread 不是万能胶：如果线程函数不接受 stop_token 参数，jthread 就退化为普通 thread，request_stop() 也无效。参数签名是契约，不是装饰。
• 析构顺序很重要：jthread 对象必须存活到线程真正结束。若它在栈上，确保作用域覆盖整个工作周期；若在堆上，别提前 delete。
• stop_callback 是锦上添花，非必需：你可以注册一个回调，在停止请求发出时触发（比如关闭日志句柄），但它不替代主动轮询——因为回调执行时机不可控，且无法打断正在运行的 do_work()。

写在最后

stop_token 解决的从来不是“如何杀死线程”，而是“如何让线程体面地、可预测地退出”。它把过去靠经验、靠注释、靠祈祷才能达成的协作，变成了类型安全、编译检查、行为确定的接口。

下次当你又要写一个后台任务线程，别急着声明 std::atomic<bool>。先问问自己：这个线程是否该知道自己“可以停”？如果是，就给它一张 stop_token——不是多加一行代码，而是少掉三处潜在竞态、两处内存序困惑、一次尴尬的 kill -9 式调试。

真正的工程效率，往往藏在让机器少猜一点、让人少担一份心的地方。