单线程时间轮通过三级分层哈希桶+裸指针+延迟析构实现O(1)摊还复杂度，规避shared_ptr原子开销、红黑树/堆的O(log n)瓶颈及cache miss，以clock_gettime+epoll timeout协同驱动。
单线程时间轮（Timing Wheel）在高频定时任务场景下，std::chrono + std::priority_queue 会因堆调整退化到 O(log n) 插入/删除，而哈希桶分治后可稳定在 O(1) 摊还复杂度——这是 C++ 实现高性能调度器的核心突破口。
为什么不用 std::set 或 boost::heap 做超时管理
它们都依赖红黑树或二叉堆，每次插入、删除、最小元素查询都是 O(log n)。当每秒新增 10 万+ 定时任务（如连接空闲检测、心跳续期），log₂(10⁵) ≈ 17 次指针跳转，CPU cache miss 显著上升；更关键的是，大量短生命周期任务（如 100ms 超时）集中到期时，连续 pop 多个节点会引发频繁内存分配与析构开销。
-
std::set迭代器失效风险高，无法安全遍历中 erase -
boost::heap::fibonacci_heap理论摊还 O(1) 插入，但常数极大，且不支持按 key 查找和批量过期扫描 - 真正需要的是「按时间槽批量归档 + 单槽内无序链表」结构，到期时只挪动指针，不调用 dtor
TimingWheel 的三级分层设计与桶索引计算
单层时间轮易受精度与跨度限制：若 tick=1ms，要支持 1h 任务就得 3.6M 槽；若 tick=100ms，则无法处理 50ms 级别任务。采用三级轮（毫秒/秒/分钟）可兼顾精度与内存，核心是统一用 uint64_t 表示绝对时间戳，并通过位运算快速映射到各层槽位。
- 底层 tick = 1ms，轮大小 = 256（2⁸），覆盖 256ms；溢出部分右移 8 位送入秒轮
- 秒轮大小 = 64（2⁶），覆盖 64s；再溢出右移 6 位送入分钟轮
- 所有槽用
std::vector<TaskNode*>存裸指针，避免 shared_ptr 计数开销 - 插入时：先算当前时间
now_ms，再对每个轮做(expire_ms - now_ms) >> shift得槽号，取余得偏移
如何避免 std::shared_ptr<Task> 引发的原子计数瓶颈
高频创建/销毁任务时，shared_ptr 的 _M_weak/_M_count 原子增减会争用同一 cache line，实测在 32 核机器上导致 20%+ 性能下降。解决方案是任务对象生命周期由调度器完全托管：
立即学习“C++免费学习笔记（深入）”；
- 所有
Task对象预先分配在std::deque<Task>中，用Task*注册，不 new/delete - 使用
std::atomic_bool Task::valid标记是否已触发，回调前 CAS 检查，避免重复执行 - 取消任务时仅置
valid = false，实际内存等到所属槽被轮转清空后再批量回收（延迟析构） - 回调函数签名强制为
void(*)(void*)，避免 std::function 的类型擦除开销
Linux 下如何绑定 epoll_wait 与时间轮驱动
不能让时间轮靠 busy-loop 或 timerfd_settime 驱动——前者耗 CPU，后者需系统调用且精度受限于 HZ。正确做法是把时间轮的最近到期时间作为 epoll_wait 的 timeout 参数：
- 每次 epoll 返回后，先执行 I/O 事件，再调用
wheel.advance(now)推进指针并收集到期任务 -
advance()内部用 while 循环跳过空槽，每跳一层更新一次最小到期时间 - 若无 I/O 事件且最近任务在 5ms 后到期，就传 5 给
epoll_wait；若无任务，传 -1 阻塞等待 - 注意：必须用
clock_gettime(CLOCK_MONOTONIC, ...)获取 now，避免系统时间回跳导致任务漏触发
真正难的不是实现多级轮或指针管理，而是让所有路径避开动态内存分配、原子操作和虚函数调用——哪怕一个 std::cout << "tick" 都可能让吞吐掉 15%。上线前务必用 perf record -e cache-misses,branches,mispredictions 检查热点。
