C++如何使用std::stop_token优雅地请求多线程安全退出-C++-PHP中文网

std::stop_token::stop_requested() 仅反映停止请求状态，不阻塞、不同步、无内存序保证，需配合 stop_callback 或在循环头部高频轮询；jthread 构造时自动绑定 stop_source 并传递 token；stop_callback 析构时执行清理，但要求对象存活且回调快速完成；多线程共享 stop_source 时各 token 独立，仍需各自轮询，不可中断系统调用需额外机制配合。

c++如何使用std::stop_token优雅地请求多线程安全退出

std::stop_token 为什么不能直接判断“是否已停止”

很多人以为 std::stop_token::stop_requested() 返回 true 就代表线程该立刻退出，但实际中常出现“检查了却没及时退出”或“反复检查拖慢性能”。根本原因是：它只反映请求状态，不阻塞、不同步、也不保证其他线程的写操作对当前线程立即可见——除非你用它配合 std::stop_callback 或在循环中合理轮询。

真正安全的做法是把 stop_requested() 放在高频可中断点（比如循环头部），并避免在长耗时操作中间忽略它。例如网络 recv 或文件读取这类阻塞调用，必须搭配超时或可取消句柄，否则 stop_token 本身无法打断。

不要在 while (true) 里漏掉检查，哪怕只有一处逻辑分支
避免在 std::this_thread::sleep_for 前检查，而应在每次唤醒后立刻再查一次
std::stop_token 是轻量值类型，拷贝安全，但别把它当成锁或条件变量来用

如何让 std::jthread 自动注册 stop_source 并响应退出

std::jthread 的核心价值不是“自动 join”，而是构造时自动绑定一个 std::stop_source，并把它的 get_token() 传给线程函数。这意味着你不用手动管理 stop_source 生命周期，也不会因提前析构导致 token 失效。

常见错误是试图在线程函数里捕获 std::stop_source 或重复创建 token —— 这既没必要，还可能引发未定义行为。正确姿势是直接接收 std::stop_token 参数，并在函数体内使用它。

void worker(std::stop_token stoken) {
    while (!stoken.stop_requested()) {
        do_work();
        std::this_thread::sleep_for(100ms);
    }
    cleanup(); // 退出前清理
}

int main() {
    std::jthread t{worker}; // 自动注入 token
    std::this_thread::sleep_for(500ms);
    t.request_stop(); // 安全触发
    // t 自动 join，无需手动调用
}

线程函数签名必须接受 std::stop_token（或更宽泛的 std::stop_token const&）
如果函数有其他参数，std::stop_token 必须放在最后，否则 std::jthread 构造时无法推导
t.request_stop() 是线程安全的，可在任意时刻从任意线程调用

std::stop_callback 在析构时执行清理的边界条件

std::stop_callback 的作用是：当关联的 std::stop_source 被请求停止时，自动调用注册的回调。但它**只保证在停止请求发生后、且 callback 对象仍存活时执行**——如果 callback 已被销毁，就不会调用。

C++ 算法竞赛自动化测试数据生成与校验框架

根据原题生成新题面、验证器及完整测试数据，自动套用 testlib 模板，用于用户要求生成测试数据时。

下载

这导致一个典型坑：在 lambda 中捕获局部变量或 this 指针，而该 lambda 的生命周期短于线程。结果就是停止请求来了，但回调早已析构，清理逻辑被跳过。

推荐把 std::stop_callback 成员变量声明为类的字段（如 std::stop_callback<decltype> m_stop_cb;</decltype>），确保与对象同寿
若用 lambda，捕获方式必须是值捕获（[=]），且所有捕获对象生命周期 ≥ 线程生命周期
回调内禁止调用可能阻塞或抛异常的函数；标准明确要求回调应“快速完成”