std::chrono + std::priority_queue 不适合高频心跳检测，因其插入/删除为 O(log n)，无法实现时间轮核心的 O(1) 批量触发和高内存局部性；槽位暴涨往往源于连接重试未清理。
为什么 std::chrono + std::priority_queue 不适合高频心跳检测
时间轮（Timing Wheel）的核心优势不是“精度高”，而是“插入/删除均摊 O(1)”和“内存局部性好”。用 std::priority_queue 实现的最小堆，每次插入和到期检查都是 O(log n)，当心跳任务达 10k+/秒、平均生命周期
真实场景中，心跳检测往往具备强周期性（如每 3 秒发一次 ping，超时阈值 9 秒），这类任务天然适配分层时间轮——不需要纳秒级精度，但要求批量到期扫描快、新增/取消延迟低。
- 避免在定时器回调里做网络 I/O 或锁竞争，只做标记+唤醒工作线程
- 不要把连接对象指针直接塞进定时器节点，改用
uint64_t session_id+ 外部哈希表查表，防止节点过期后访问已析构对象 - 若使用多线程调度（如一个线程负责 tick，一个线程负责执行到期任务），必须对时间轮槽位加细粒度锁（每个槽一把
std::shared_mutex），而非全局锁
三层时间轮结构怎么配参数才不翻车
典型配置是：第一层（毫秒轮）64 槽、每槽 1ms，覆盖 64ms；第二层（秒轮）60 槽、每槽 1s，覆盖 60s；第三层（分钟轮）60 槽、每槽 1m，覆盖 60min。这个设计不是拍脑袋来的——它让 99% 的心跳任务落在第一层，只有超时重试类长周期任务才降级到外层。
关键陷阱在于“tick 频率”和“槽位数”的匹配：
立即学习“C++免费学习笔记（深入）”；
- 如果第一层设 100 槽但每 10ms tick 一次，实际分辨率就退化成 10ms，且 100 槽有 90 个永远空转，浪费 L1 cache
- 若心跳周期是 3000ms，但第二层每槽 1000ms，那么 3000ms 任务会被挂到第 3 个槽，而 2999ms 和 3001ms 任务却可能跨槽，导致非预期的顺序偏差
- 推荐固定 tick 周期为 1ms，所有轮子按 2 的幂次设计槽位（如 64、256、1024），方便用位运算取模，避免除法指令
add_task() 必须支持优先级插队，但不能破坏时间轮结构
心跳检测里常需“紧急重连”或“强制下线”，这类任务要插在当前 tick 对应槽的最前面执行，而不是等自然到期。时间轮本身不维护槽内顺序，所以得给每个槽配一个带优先级的小顶堆或双向链表。
实操建议选双向链表（std::list 或自定义内存池链表），原因很实在：
- 堆需要为每个节点分配内存 + 维护堆序，而链表插入 O(1)，遍历时 CPU prefetch 友好
- 优先级字段建议只用 2 bit：0=普通心跳，1=重连，2=强踢出，3=保留；用位运算比
std::less<int></int>快得多 - 禁止在
add_task()里做深拷贝，传入的task_data应是std::shared_ptr或仅存session_id，由执行阶段再查表获取完整上下文
如何验证时间轮没漏任务也没重复触发
最有效的办法不是加日志，而是在时间轮内部埋两个原子计数器：total_inserted 和 total_fired。每次插入递增前者，每次真正调用用户回调前递增后者。运行 1 小时后检查两者是否相等——不等说明有任务被跳过或重复。
另一个易忽略点是“tick 超时漂移”：如果系统负载高，某次 tick() 耗时 3ms，而你期望 1ms 一 tick，那这轮就会漏掉 2ms 内到期的所有任务。解决方案是记录上一次 tick 时间戳，每次计算应处理多少轮：
auto now = Clock::now();
auto elapsed_ms = duration_cast<milliseconds>(now - last_tick_).count();
int rounds = elapsed_ms / tick_ms_; // tick_ms_ == 1
for (int i = 0; i < rounds; ++i) {
advance_wheel();
}
last_tick_ = now - milliseconds(elapsed_ms % tick_ms_);
注意这里用的是 elapsed_ms / tick_ms_ 向下取整，不是四舍五入，否则在 tick 漂移剧烈时可能误推进过多轮次。
调试阶段可临时开启“槽位占用率统计”，每 10 秒打印各层最高负载槽的节点数，若第一层常年 > 100 节点/槽，说明 tick 频率太低或槽位太少；若第三层某槽突然暴涨，大概率是有连接卡在重试逻辑里没清理干净。
