多级时间轮通过分层哈希结构实现O(1)均摊操作，支持长延迟定时任务；需用原子计数器驱动逻辑时间、细粒度锁保护槽、atomic_bool标记过期、无锁队列对接线程池，并确保降级与生命周期管理的内存序正确。
时间轮调度器在 C++ 中不是“开箱即用”的标准组件，直接用 std::chrono + std::thread 手搓容易掉进精度丢失、任务堆积、内存泄漏、线程竞争这四个坑里——尤其当定时任务量超过 1000 个/秒时，std::set 或 std::priority_queue 驱动的最小堆方案会明显退化。
为什么哈希时间轮比堆更适合作为高频定时器底层
堆每次插入/删除是 O(log n)，而单层哈希时间轮（如 64 槽 + 256ms 精度）所有操作都是 O(1) 均摊；但前提是任务延迟不能超过一轮周期（比如最大支持 256ms 延迟）。真实业务中往往需要支持数小时后执行的任务，这就必须用多级时间轮（hierarchical timing wheel），类似 Linux 内核的 timer_list 设计：低精度轮溢出时降级到高一级轮上。
- 一级轮（毫秒级）：64 槽，每槽代表 16ms，总跨度 1024ms
- 二级轮（秒级）：64 槽，每槽代表 1s，总跨度 64s
- 三级轮（分钟级）：64 槽，每槽代表 1min，总跨度 64min
- 超出三级范围的任务，直接挂到一个链表里走兜底轮询（极少触发）
关键点在于：**降级动作只在插入时发生一次，且仅涉及指针移动，不拷贝任务对象**；每个槽用 std::vector 存任务句柄（如 std::shared_ptr<timertask></timertask>），避免节点分配开销。
std::atomic<uint64_t></uint64_t> 时间戳推进与 tick 同步问题
不要用系统调用 clock_gettime() 实时读取时间来驱动 tick——高并发下它可能成为瓶颈。正确做法是用单个后台线程以固定间隔（如 16ms）递增一个全局 std::atomic<uint64_t></uint64_t> 计数器，所有轮子都基于这个逻辑时间推进。
立即学习“C++免费学习笔记（深入）”；
- tick 线程必须用
std::this_thread::sleep_for()对齐间隔，但要预防系统休眠导致的 drift：每次 sleep 前记录期望下次 tick 时间，醒来后用now - expected 判断是否跳过若干 tick - 任务插入时，先用原子读拿到当前逻辑时间，再计算应落入哪一级哪一槽；插入过程需对目标槽加细粒度锁（如
std::shared_mutex），而非全局锁 - 避免用
std::chrono::steady_clock::now()直接参与槽索引计算——它的纳秒值太大，做模运算易引发分支预测失败
任务取消与资源安全销毁的典型误操作
用户调用 cancel() 后，任务对象不能立即析构，因为可能正处在某个槽的 std::vector 中被遍历。常见错误是让 TimerTask 继承 std::enable_shared_from_this，然后在回调里调用 shared_from_this() ——一旦任务已 cancel 但尚未从轮中移除，就会抛 bad_weak_ptr。
- 正确做法：任务结构体里带一个
std::atomic_bool expired{false}，cancel()只设为 true；执行回调前先检查该标志 - 移除任务必须由 tick 线程完成：每次 tick 扫描槽时，把
expired == true的任务从std::vector中 swap 删除（用erase-removeidiom 会触发多次移动，不推荐） - 若任务持有外部资源（如 socket fd），应在
on_expire()回调里显式释放，而不是依赖析构函数——析构时机不可控
如何对接业务线程池而不引入锁竞争
时间轮只负责“何时触发”，不负责“在哪执行”。把回调扔进业务线程池是刚需，但直接在线程池里调用用户回调会导致：① 用户回调阻塞拖慢整个池；② 多个任务同时回调可能压垮池子。
- 建议在 tick 线程中把到期任务包装成轻量
std::function<void></void>，然后用无锁队列（如moodycamel::ConcurrentQueue）投递给业务线程池 - 避免在 tick 线程里做任何用户态 IO 或内存分配；回调包装应提前在任务创建时完成（如用
std::bind+ 捕获移动语义） - 如果业务要求强顺序（如同一 key 的任务必须串行），不要靠时间轮保证——应在业务线程池外加一层 key-hash 分发器，把同 key 任务路由到同一 worker 线程
多级时间轮真正的复杂点不在结构，而在“降级路径的原子性”和“跨线程生命周期管理”。哪怕只漏掉一个 memory_order_acquire，都可能导致任务静默丢失。别迷信模板元编程优化槽索引计算——先跑通正确性，再用 perf record 看热点。
