std::async + std::future::wait_for 无法可靠取消定时任务，因其不支持协作式取消机制，任务需自行轮询 stop_token 等退出信号；C++20 的 std::jthread + std::stop_token 是推荐方案，配合原子状态与 RAII 可安全实现重排程。
为什么 std::async + std::future::wait_for 无法可靠取消定时任务
因为 std::async 启动的任务是“fire-and-forget”式执行，std::future 的 wait_for 或 wait_until 只能阻塞等待结果，**无法通知任务本体提前终止**。C++ 标准库中没有内置的可取消异步任务抽象——所谓“取消”，必须由任务自己轮询检查退出信号，而不是由调度器强行中断线程。
常见错误现象：std::future::wait_for(100ms) 返回 std::future_status::timeout，但底层线程仍在跑，甚至已修改了共享状态，导致后续逻辑错乱。
- 任务必须显式接受一个
std::atomic<bool>& stop_token</bool>或std::stop_token（C++20）作为运行守卫 - 所有耗时操作（如
sleep_for、循环计算、IO 等）中间需插入检查点，例如if (stop_token.load()) return; - 不要依赖
std::thread::joinable()或std::future::valid()判断任务是否“还在运行”——它们不反映逻辑生命周期
C++20 std::jthread + std::stop_token 是最简可行取消方案
std::jthread 自动管理线程生命周期，且内置 std::stop_source，配合 std::stop_token 可实现协作式取消。它不是“魔法”，但把样板代码压缩到了最低。
auto schedule_once = [](auto&& f, auto delay) {
std::jthread t([f = std::move(f), delay](std::stop_token stoken) {
if (stoken.stop_requested()) return;
std::this_thread::sleep_for(delay);
if (!stoken.stop_requested()) f();
});
return t; // 返回 jthread，后续可调用 t.request_stop()
};
使用场景：单次延迟执行（如超时清理、防抖回调）。重排程需手动 request_stop() 后新建 jthread；精确取消即调用 t.request_stop()，之后线程会在下一次 stoken.stop_requested() 检查时退出。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 注意
std::jthread构造后立即启动，不可延迟启动 -
std::stop_token是轻量拷贝对象，可安全传入 lambda 捕获 - 若任务内含阻塞系统调用（如
read()），需配合signalfd或eventfd（Linux）或WaitForMultipleObjects（Windows）实现响应式中断，仅靠stop_token不够
如何支持重排程（reschedule）而不泄漏线程或丢失状态
重排程本质是「取消旧任务 + 提交新任务」，难点在于避免竞态：旧任务可能刚检查完 stop_token 就被取消，随后仍执行关键逻辑；或新任务在旧任务尚未完全退出时就写入共享数据。
推荐用原子指针 + RAII 封装状态：
struct TimerTask {
std::atomic<bool> cancelled{false};
std::function<void()> fn;
std::shared_ptr<std::atomic<bool>> active_flag;
void operator()() {
if (cancelled.load(std::memory_order_acquire)) return;
if (!active_flag->load(std::memory_order_acquire)) return;
fn();
}
};
// 重排程函数
std::shared_ptr<std::atomic<bool>> reschedule(
std::shared_ptr<std::atomic<bool>>& old_flag,
std::function<void()> new_fn,
std::chrono::milliseconds delay)
{
if (old_flag) old_flag->store(false, std::memory_order_release);
auto new_flag = std::make_shared<std::atomic<bool>>(true);
std::jthread([f = std::move(new_fn), flag = new_flag, delay] {
std::this_thread::sleep_for(delay);
if (flag->load(std::memory_order_acquire)) f();
});
return new_flag;
}
-
active_flag用于跨重排程周期标记“此任务实例是否仍应生效” - 旧任务不直接销毁，而是通过
cancelled和active_flag双重防护，确保不会误执行 - 返回
std::shared_ptr<:atomic>></:atomic>给上层持有，便于后续再次重排或强制失效
要不要自己写调度框架？先看 std::chrono + 单线程事件循环是否够用
90% 的业务级定时需求（如心跳、缓存刷新、重试退避）不需要多线程调度器。一个基于 std::priority_queue + std::chrono::steady_clock 的单线程驱动器更轻量、无锁、易调试。
核心结构：
using TaskId = size_t;
struct Task {
TaskId id;
std::chrono::steady_clock::time_point when;
std::function<void()> fn;
bool operator>(const Task& rhs) const { return when > rhs.when; }
};
std::priority_queue<Task, std::vector<Task>, std::greater<Task>> queue;
std::mutex queue_mutex;
std::condition_variable cv;
std::atomic<bool> running{true};
// 主循环
while (running) {
std::unique_lock<std::mutex> lk(queue_mutex);
cv.wait_until(lk, queue.top().when, [&]{ return !queue.empty(); });
if (!queue.empty() && queue.top().when <= now()) {
auto task = std::move(queue.top()); queue.pop();
lk.unlock();
task.fn(); // 在调度线程中执行，避免频繁切线程
}
}
- 精确性取决于
wait_until系统调用精度（Linux 上通常 1–15ms，取决于 timer slack 和调度延迟） - 所有任务回调都在同一调度线程中执行，天然串行，无需额外同步
- 取消/重排程只需操作队列：移除旧任务、插入新任务，并
notify_one() - 别过早抽象成“框架”——先用这个 loop 跑满一周压测，再决定是否引入
boost.asio或自研多队列分片
真正容易被忽略的是时钟源漂移和任务执行时间溢出：如果某个 fn() 执行了 200ms，而队列里还有 50ms 后触发的任务，它会立刻被拉出执行，但实际已晚点。这种偏差必须在业务逻辑里容忍或补偿，没法靠调度器“自动对齐”。
