std::chrono+std::priority_queue不适合高频定时任务，因其插入/删除为O(log n)且无法高效取消任务，导致堆重排、缓存不友好、无效遍历及延迟抖动；应改用分层时间轮实现均摊O(1)与无锁取消。
为什么 std::chrono + std::priority_queue 不适合高频定时任务
因为每次插入/删除都要 O(log n)，当每秒新增上万次定时任务（比如连接超时、心跳续期），堆操作会成为瓶颈；更关键的是，std::priority_queue 无法高效取消已入队但未触发的任务——只能标记失效，导致无效遍历和内存泄漏风险。
真实场景中，你常会看到 CPU 在 std::make_heap 或 __pop_heap 里持续打转，top() 返回的也不是“最近要触发的”，而是堆顶，需反复 pop() + 检查是否过期，逻辑混乱且不可控。
- 高频写入（如每毫秒注册几十个连接超时）→ 堆频繁重排 → 缓存不友好
- 任务取消靠外部标记 → 扫描时仍要遍历所有待处理节点 → 延迟毛刺明显
- 无法按时间分片调度 → 难以做 tick 分摊，单次 tick 处理耗时抖动大
时间轮结构选型：分层时间轮比单层更实用
单层哈希时间轮（如 64 槽 × 10ms）只适合固定精度、短周期场景；一旦要支持 1s～24h 范围、毫秒级精度、动态增删，必须用多级。典型做法是 4 层：毫秒轮（256 槽）、秒轮（64 槽）、分钟轮（64 槽）、小时轮（24 槽），每层槽位数取 2 的幂，方便位运算取模。
关键不是层数多，而是「溢出迁移」逻辑必须无锁且 O(1)。比如毫秒轮走完一圈（256ms），就把所有挂载在第 0 槽的定时器，按剩余时间重新映射到秒轮对应槽位——这个过程不能遍历、不能加锁、不能分配新内存。
- 每层使用
std::vector<:list>>，避免指针跳转开销 - TimerNode 内联存储回调函数对象（
std::function或 move-only lambda），避免额外 heap alloc - 用
uintptr_t+ tag bit 标记是否已取消，取消操作仅原子置位，不涉及链表摘除
tick() 怎么做到低延迟、可预测、不丢 tick
不要依赖系统 sleep 或条件变量等待，那会导致 jitter。正确做法是用 clock_gettime(CLOCK_MONOTONIC, &ts) 获取当前绝对时间，再算出本 tick 应该推进到哪个时间点；然后 while 循环推进各层时间轮，每一层只处理「当前 tick 时间落在其槽位内」的部分。
重点：tick 步长不是固定值（比如死守 1ms），而是由上次 tick 到本次实际耗时决定。如果上次处理花了 1.8ms，这次就从 t+1.8ms 开始推进，避免累积误差和漏触发。
- 每层推进前先算
elapsed = now - last_tick_time，再换算成该层的 tick 偏移 - 毫秒轮每槽代表 1ms，秒轮每槽代表 1s —— 换算靠整数除法 + 余数，不用浮点
- 若某次
tick()耗时 > 单层最小粒度（如 1ms），则跳过多轮，但必须保证「所有已到期任务至少被执行一次」，不能因跳过而遗漏
如何安全取消一个正在运行的定时任务
真正高效的取消不是从链表里删节点（那需要遍历+锁），而是让执行阶段自己跳过。每个 TimerNode 包含一个 std::atomic，低 2 位用于标记状态（0=active, 1=canceled, 2=executing, 3=done），高位存原始回调指针。
注册时写入完整指针；取消时仅 CAS 置为 canceled；执行前检查 state 是否仍为 active，否则直接 return。这样取消是纯原子操作，平均耗时
- 禁止在回调里调用
cancel()自身（可能造成 ABA 或 double-free），应改用 post-cancellation 模式 - 如果回调本身是 long-running，需额外加
std::atomic让其主动轮询退出*canceled_flag - 注意
std::function移动后原对象变为 empty，别误判为已取消
最易被忽略的一点：时间轮的「当前指针」必须用 relaxed memory order 读取，但跨层迁移时的槽位更新必须用 release-acquire 配对，否则秒轮可能看不到毫秒轮刚迁出的任务。这层同步细节，90% 的开源实现都错了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
