C++如何使用std::stop_callback在任务取消时执行清理-C++-PHP中文网

std::stop_callback 是绑定到 std::stop_source 生命周期、仅在 stop_token 被明确请求停止且尚未停止时触发一次的 RAII 回调；它不响应线程退出或作用域结束，需栈上持有或成员变量持久化以确保生效。

c++如何使用std::stop_callback在任务取消时执行清理

std::stop_callback 是什么，它在什么场景下才真正生效

std::stop_callback 不是“注册一个随时能调用的回调”，而是绑定到 std::stop_source 的生命周期，并仅在关联的 stop_token 被请求停止（即 request_stop() 被调用）且该 token 尚未被停止时，自动触发一次。它不响应线程退出、异常退出或作用域结束——只响应明确的停止请求。

常见错误现象：

回调函数没执行 → 很可能 std::stop_source 已被销毁，或 stop_token 已处于 stopped 状态（token.stop_requested() 返回 true），此时构造 std::stop_callback 会直接忽略回调
回调执行了两次 → 错误地在循环中反复构造新 std::stop_callback 对象，而旧对象尚未析构（每个实例只触发一次，但多个实例各自触发）

使用场景：

长时间运行的 worker 线程中监听取消信号并释放资源（如关闭文件句柄、取消 pending I/O）
在协程或异步任务中，配合 std::jthread 自动管理停止逻辑

如何正确构造并保持 std::stop_callback 生效

std::stop_callback 是 RAII 类型，其析构会自动注销回调。因此它必须存活到停止请求发生之后，否则注册即失效。

关键点：

必须用 std::stop_token 构造（不能传 std::stop_source.get_token() 的临时对象）
推荐在栈上持有，或在类成员中持久化（避免悬垂引用）
回调捕获的变量需确保生命周期 ≥ std::stop_callback 对象本身

示例（安全写法）：

std::jthread t([](std::stop_token stoken) {
    // ✅ 正确：callback 对象在栈上，生存期覆盖整个 lambda 执行
    std::stop_callback cb(stoken, []{
        std::cout while (!stoken.stop_requested()) {
    // do_work();
    std::this_thread::sleep_for(100ms);
}

});

错误写法（回调永不触发）：

// ❌ 错误：token 是临时对象，stoken 停止状态不可靠，cb 构造可能直接跳过
std::stop_callback cb(std::stop_source{}.get_token(), []{ /*...*/ });

为什么 std::stop_callback 无法捕获异常，以及怎么绕过

std::stop_callback 的回调函数若抛出异常，程序会直接调用 std::terminate() —— 标准明确禁止在其中抛异常。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

这不是设计疏漏，而是为了保证停止语义的确定性：取消路径必须快速、无副作用、不可中断。

所以：

回调体内所有操作必须是 noexcept（或至少用 try/catch 吞掉异常）
不要调用可能抛异常的 STL 容器操作（如 std::vector::push_back）、new、std::cout（虽然通常不抛，但非 guaranteed noexcept）
清理动作尽量轻量：关闭 fd、置 flag、调用 close()（POSIX）、closesocket()（Win）等系统级无异常接口

示例（安全清理）：

std::stop_callback cb(token, [&fd]{
    if (fd != -1) {
        ::close(fd); // POSIX，noexcept
        fd = -1;
    }
});

和 std::jthread 配合时最容易忽略的生命周期陷阱

std::jthread 析构时会自动调用 request_stop() 并 join()，但它的 std::stop_source 成员在析构末尾才销毁。这意味着：

如果你在 std::jthread 对象作用域外还保留着它的 get_stop_token()，那个 token 可能已无效（析构后访问是未定义行为）
更隐蔽的是：把 std::stop_callback 存在全局/静态对象里，而该对象析构晚于 std::jthread → token 失效，回调静默失败

容易踩的坑：

把 std::stop_callback 放进 std::shared_ptr 并跨线程传递 → 若原始 std::jthread 已结束，token 可能已失去关联
在类中保存 std::stop_token 成员，但没同步管理 std::stop_callback 生命周期 → token 还在，但对应 stop_source 已销毁

最稳妥的做法：