C++使用Boost.Asio怎么实现定时器任务-C++-PHP中文网

asio::steady_timer是最稳妥的定时器选择，基于单调时钟避免系统时间跳变导致的任务错乱，应优先于system_timer和已弃用的deadline_timer使用。

c++使用boost.asio怎么实现定时器任务

asio::steady_timer 是最稳妥的定时器选择

Boost.Asio 提供了两种主要定时器：asio::steady_timer 和 asio::system_timer。除非你明确需要系统时钟（比如和日志时间戳对齐），否则一律用 steady_timer——它基于单调时钟，不受系统时间跳变影响，避免定时任务突然提前或延后执行。

常见错误是直接用 system_timer 做周期性轮询，结果在 NTP 调时或手动改系统时间后，任务乱序甚至重复触发。

实操建议：

steady_timer 构造时传入 io_context 和初始超时（如 std::chrono::seconds(5)）
回调必须通过 async_wait() 注册，不能用 wait() 阻塞，否则会卡死整个 io_context
每次触发后，如需重复执行，得在回调里重新调用 async_wait()（别忘了重设到期时间）

如何安全地在回调中重启周期性定时器

很多人写成“触发 → 执行逻辑 → 立即 async_wait()”，看似没问题，但若执行逻辑耗时较长，下一次触发会被挤压，导致实际间隔越来越短，甚至堆积。

正确做法是把“重设定时器”和“业务逻辑”解耦，用固定间隔推进，而不是链式等待：

void start_periodic_timer() {
  timer_.expires_after(std::chrono::seconds(1));
  timer_.async_wait([this](const boost::system::error_code& ec) {
    if (ec == boost::asio::error::operation_aborted) return;
    do_work(); // 你的任务逻辑
    // 关键：不管 do_work 耗多久，都从“上一次设定的到期点”开始算下一个周期
    timer_.expires_at(timer_.expiry() + std::chrono::seconds(1));
    start_periodic_timer(); // 递归调度
  });
}

注意：expires_at() 比 expires_after() 更可控；递归调用比在回调末尾直接 async_wait() 更易维护边界条件。

定时器对象生命周期管理容易出错

最常见的崩溃原因是：定时器回调还在队列里，而持有它的对象（比如 class TaskManager）已经被析构了。Asio 不会自动取消未完成的异步操作。

C++14

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

下载

必须显式保证定时器对象存活到回调结束，或主动取消：

把 asio::steady_timer 成员变量放在类里，且该类生命周期长于定时器使用期
在类析构函数中调用 timer_.cancel()，并确保所有回调里检查 ec == boost::asio::error::operation_aborted
如果用 std::shared_ptr 管理宿主对象，回调捕获 shared_from_this()，防止提前释放

漏掉 cancel() 或忽略 operation_aborted 错误码，十有八九会 crash 在回调里访问已销毁成员。

不推荐用 deadline_timer（已弃用）

旧代码里常看到 asio::deadline_timer，它底层用 boost::posix_time，不仅精度差、跨平台行为不一致，而且自 Boost 1.70 起已被标记为 deprecated。新版 Asio 文档明确建议迁移到 steady_timer 或 system_timer。

迁移成本很低：