如何使用std::stop_callback实现多线程任务取消及异步编程模型？

本文共计765个文字，预计阅读时间需要4分钟。

markdown在 Python 中，`stop_callback` 不会自动取消任务，也不会中断线程执行。它只在调用 `request_stop()` 时被触发，且仅在对象仍然存活时执行一次你指定的函数。

为什么注册了 std::stop_callback 却完全没触发？

最常见原因是生命周期管理失败——std::stop_callback 是 RAII 类型，构造即注册，析构即注销。一旦它离开作用域（比如定义在 lambda 内部），就立刻失效。

• 错误写法：std::jthread t([](std::stop_token token) { std::stop_callback cb(token, []{ cleanup(); }); /* ... */ }); → cb 在线程函数返回时销毁，后续 t.request_stop() 无回调可调
• 正确做法：把 std::stop_callback 定义在和线程同生命周期的作用域，例如紧挨着 std::jthread 声明之后：

  std::jthread t([](std::stop_token token) { /* work loop */ });<br>std::stop_callback cb(t.get_stop_token(), []{ cleanup(); });

• 更稳妥的选择：直接在任务函数里轮询 token.stop_requested()，省去生命周期判断负担

std::stop_callback 适合干啥、不适合干啥？

它真正有用的地方，是做“非任务主逻辑”的清理动作，比如释放跨线程共享资源、关闭全局日志句柄、通知外部系统等。

• 适合：std::ofstream 关闭、std::shared_mutex 解锁、记录取消日志
• 不适合：sleep_for、write() 等可能阻塞的操作；也不该在里面加锁等待其他线程完成——回调不重入、不保证执行顺序、卡住会影响整个 stop 流程
• 多个 std::stop_callback 可绑定到同一 std::stop_token，但标准不保证执行顺序，别让它们互相依赖

和 std::jthread 配合时最容易忽略的坑

std::jthread 自带 std::stop_source，但它的 std::stop_token 是线程私有的，不能被其他线程直接监听或广播。

立即学习“C++免费学习笔记（深入）”；

• 误以为 t.get_stop_token() 能让外部线程感知停止信号 → 实际上它只反映本线程是否收到请求，无法跨线程传播
• 想让多个线程响应同一取消信号？必须用外部 std::stop_source，再通过 get_token() 分发给各线程
• std::jthread 析构时会自动 request_stop() + join()，但如果 std::stop_callback 已提前析构，这次请求就彻底静默失效

最难的不是写回调函数，而是确保它活得到被调用的那一刻，同时不干扰主线程节奏。很多崩溃和静默失效，都出在“以为注册了就万事大吉”，却忽略了作用域和所有权。