time_wheel::add_timer()必须用绝对时间戳,因相对delay在多线程插入和tick不稳时易致slot集体漂移;应统一用steady_clock::now().time_since_epoch().count()转毫秒存expire_time,避免system_clock跳变,并插入前检查是否已过期。

std::chrono + std::thread 不能撑住万级定时任务,不是精度问题,是设计反模式——每任务一线程、每任务一 sleep、每到期一扫描,三重开销叠加直接让吞吐断崖下跌。
为什么 time_wheel::add_timer() 必须用绝对时间戳而非相对 delay
相对 delay(比如传入 500ms)在多线程插入时极易因调度延迟导致计算偏移;更严重的是,若底层 tick 驱动不稳(如 timerfd 漏 tick 或 epoll_wait 被阻塞),所有基于当前时间推算的 slot 位置都会集体漂移。
正确做法是统一用 std::chrono::steady_clock::now().time_since_epoch().count() 得到纳秒级绝对时间戳,再转成毫秒整数,作为 expire_time 存入节点。这样无论插入时机如何抖动,到期判断只依赖单次读取的全局单调时钟。
- 别用
system_clock:它可能被 NTP 调整,导致定时器提前或跳过 - 别在构造函数里现场算
now() + delay:如果对象跨线程传递,now()值已过期 - 插入前务必检查
expire_time ,这类“已过期”任务应立即投递,不进轮子
优先级怎么嵌进 time_wheel::tick() 不拖慢遍历性能
不能在每个 bucket 里套一个 std::priority_queue,否则遍历时要对桶内全部任务做堆 pop,复杂度从 O(k) 变成 O(k log k),k 是桶内任务数——100 个同 tick 高频任务就能吃掉 20% CPU。
真正高效的做法是把优先级编码进排序键:用 (expire_time 构造 uint64_t 主键,在桶内用 <code>std::list 存储,插入时按主键有序插入(O(k) 扫描找位点),但 tick 触发时仍可顺序遍历执行(O(k))。关键在于:同一毫秒内高优先级任务一定排前面,而跨毫秒任务严格按时间先后。
-
priority建议用 2 bit 编码(0–3),避免左移后溢出或干扰时间高位 - 比较函数中必须用
>(因为std::priority_queue默认大顶堆),但你不用它——改用带哨兵的链表插入更可控 - 如果业务要求「同时间下优先级完全抢占」,就别省那点插入开销,老实用
std::vector<timertask></timertask>+std::sort每次 tick 前局部排序
多级时间轮降级时最常踩的坑:rotation 计算错误
单层轮子覆盖范围有限(比如 64 槽 × 256ms = ~16s),长周期任务必须降级到低频层。常见错误是直接拿剩余时间除以新层粒度,忽略“已走过圈数”的余数归属。
例如:一个 120s 任务在毫秒层(粒度 1ms)会算出 120000 圈,显然不合理。应先按层级粒度分级:第 0 层(毫秒)管 0–255ms,第 1 层(秒)管 1–63s,第 2 层(分钟)管 1–63min……每层槽数固定为 64,降级公式为:level = min(7, __builtin_clzll(timeout_ms) - 56)(GCC/Clang),然后用 timeout_ms >> (level * 6) 算该层 offset,再取模得 slot。
- 别用浮点
log2:慢且有精度误差,__builtin_clzll是位运算,零误差 - 降级后必须重算剩余时间,不是简单减去上层最大值——否则 65s 任务会落到秒层 slot 1,实际应是 slot 1、level 1、rotation 0
- 所有层级共享同一 tick 源(如 timerfd),但每层有自己的指针和旋转计数器,不能共用 current_slot_
timerfd + epoll 驱动 time_wheel::tick() 时 read() 必须非阻塞
一旦 timerfd 设置为阻塞模式,read(tfd, &exp, sizeof(uint64_t)) 在没有到期事件时会挂起整个事件循环,epoll_wait 就卡死,所有网络 IO 和定时任务全停摆。
初始化必须加 TFD_NONBLOCK 标志:int tfd = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK);。收到 EPOLLIN 事件后,read 返回 -1 且 errno == EAGAIN 是正常现象,说明本次 tick 已被清空,直接调用 tick() 即可;若返回 8 字节,则 exp 是自上次以来触发次数,需循环调用 tick() 多次(防止漏 tick)。
- 别在 epoll 回调里直接执行用户回调:可能抛异常或阻塞,应 push 到工作线程池
-
it_interval必须设为非零值,否则只触发一次,轮子就停了 - 每次
read后必须清空计数,否则下次 EPOLLIN 不会再通知——这是 timerfd 的语义,不是 bug
真正难的不是写完八层轮子,而是让每一层的 rotation、每一槽的插入顺序、每一次 read 的计数清空都咬合严丝合缝。任何一处错位,都会在高负载下放大成毛刺、漏触发或内存泄漏——这些地方没日志、不报错,只能靠 perf record + 自定义 tracepoint 抓。
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!











