如何精确取消异步定时任务？使用stop_token实现协作式处理技巧分享。

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

异步定时任务的精确取消，不能依赖于停止线程或杀死句柄等方法——std::stop_token。它不提供强制中断能力，只提供协作式的中断信号。真正能够精确取消的关键，在于你将检查点放在何处、如何与定时器协同以及如何避免信号已发出但任务未注意到的空窗期。

为什么 std::this_thread::sleep_for 无法被 stop_token 直接中断

这是最常踩的坑：std::this_thread::sleep_for 是阻塞调用，不响应 std::stop_token。即使你在别处调用了 source.request_stop()，睡眠中的线程也不会提前醒来。

• 必须改用带超时的轮询方式：例如 std::this_thread::sleep_for(10ms) + 紧接着检查 token.stop_requested()
• 若底层使用 epoll_wait() 或 timerfd，需手动唤醒（如向配套 pipe 写入字节），否则 stop_token 只是“挂起状态”，无实际效果
• 协程中更危险：直接 co_await std::chrono::seconds{5} 不会响应 cancel；必须用支持 std::stop_token 的 awaiter（如 cppcoro 的 when_all_ready 或自定义 timeout wrapper）

在定时循环中嵌入 stop_token 检查的正确位置

检查不能只做一次，也不能只在循环开头——要覆盖所有可能长时间停留的路径。

• 每次迭代开始前：防止刚进入循环就收到取消
• 每次 I/O 调用（如 read()、recv()）之前和之后：系统调用可能阻塞，且返回后需确认是否仍应继续
• 每次 sleep_for 或 wait_for 返回后：这是最典型的“醒来即检查”时机
• 避免写成 if (!token.stop_requested()) { /* 整个 for 循环 */ } —— 这样一旦触发，后续所有迭代全跳过，但任务逻辑实际并未“响应取消”，只是“跳过了执行”

跨线程传递 stop_source 时生命周期管理要点

把取消能力暴露给异步任务，本质是传递一个 std::stop_source 的副本。但它不是智能指针，析构行为需明确控制。

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

• 局部 std::stop_source source; + [token = source.get_token()]() mutable { ... } → 错误：lambda 可能延迟执行，而 source 已析构，token.stop_possible() 返回 false，后续所有检查都失效
• 正确做法一：用 std::jthread 自带的 stop_source，它与线程生命周期绑定，安全可靠
• 正确做法二：将 std::stop_source 作为类成员变量持有，或用 std::shared_ptr<:stop_source></:stop_source> 显式延长生命周期
• 注册清理回调时，std::stop_callback 构造函数内不能阻塞或做耗时操作，否则会拖慢整个取消流程

结合 timerfd 实现高精度可取消定时器的关键补丁

Linux 下用 timerfd 做异步定时器时，stop_token 本身不触发 fd 就绪。必须人工注入事件让 epoll_wait 返回，才能进检查逻辑。

• 创建 timerfd 后，额外绑一个 eventfd 或 pipe，用于接收 cancel 信号
• 在 source.request_stop() 之后，向该 eventfd 写入 8 字节整数（eventfd_write）或向 pipe 写入任意字节
• epoll_wait 返回后，先读取 timerfd（判断是否真超时），再检查 token.stop_requested()；两者任一成立，都视为应退出
• Workflow 等高性能框架正是这么干的：红黑树管理到期时间，timerfd 控制最小超时，eventfd 承担 cancel 注入，三者协同实现微秒级响应

真正难的不是“怎么发取消信号”，而是“怎么确保信号必达且必被响应”。高频检查点、非阻塞等待、跨线程对象生命周期、系统级唤醒机制——这四层缺一不可。漏掉任何一层，都会出现“调了 request_stop() 却等了几秒才退出”的现象。