为什么 std::chrono + std::thread 做不了真正毫秒级稳定定时器
因为操作系统调度、线程唤醒延迟、时钟源精度三者叠加后，std::this_thread::sleep_until 在 1–10ms 区间抖动常达 5–20ms，尤其在负载高或非实时内核上。这不是代码写得不够“精确”，而是用户态 sleep 本质依赖系统 timer tick 和调度器，无法绕过。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 别用
while(true) { sleep_for(1ms); do_work(); }—— 累积误差大，且 CPU 空转浪费 - 避免在普通 Linux 桌面环境强求 ±0.5ms 精度；若真需要，得配
CONFIG_HIGH_RES_TIMERS=y+SCHED_FIFO+ 锁内存 + 绑核 - 时间轮不是为了“更准”，而是为了“大量任务下低开销+可预测延迟”——它把 O(n) 插入/检查降为 O(1)，这才是关键
TimeWheel 的层级设计怎么选：单层还是多层？
单层时间轮（如 64 槽 × 1ms）最多覆盖 64ms，超时任务只能降级进“溢出桶”再退化成链表扫描——这会破坏 O(1) 保证。多层时间轮（如 3 层：毫秒/秒/分钟）能覆盖大范围又保持摊还 O(1)，但每层槽位数和步长要对齐。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 第一层必须是硬件时钟最稳的粒度：x86 上
rdtsc或CLOCK_MONOTONIC_RAW可支撑 0.5–1ms 分辨率，别设 0.1ms —— 没意义还占内存 - 各层槽位数推荐 64 或 256（2 的幂），方便位运算取模；避免 100 这种数，除法慢
- 第二层步长 = 第一层总跨度（如 64ms），第三层 = 第二层总跨度（如 64×64ms ≈ 4s），这样跨层迁移只发生在整倍数时刻，无舍入误差
如何让 TimeWheel::tick() 不丢帧也不卡主线程
常见错误是让 tick 主动遍历所有槽——一旦某次 tick 耗时超过步长时间（比如 1ms 内没跑完），下一 tick 就被跳过，任务延迟直接 +1 步长。正确做法是用单调时钟驱动 tick 频率，而非固定 sleep。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
clock_gettime(CLOCK_MONOTONIC, &ts)获取当前时间，算出该 tick 到哪一层哪一槽，**跳过多余 tick**，不补、不攒、不重放 - tick 函数本身必须无锁、无分配、无虚调用；任务回调用
std::function存储？立刻换掉——改用 void* + 函数指针 + 小缓冲区，否则 cache miss 严重 - 如果业务允许，把 tick 放进独立线程，但别用
std::thread默认栈（默认 2MB）；用pthread_attr_setstacksize设为 64KB，减少 TLB 压力
Linux 下 timerfd_create 能替代时间轮吗？
不能。timerfd 是内核 timer 封装，精度确实高（纳秒级），但它只支持单一定时器，创建/修改/删除都是系统调用，频繁增删任务（比如每秒上千次）会导致上下文切换雪崩。时间轮是纯用户态数据结构，增删都是指针操作。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用 timerfd 适合长期存活、极少变动的定时器（如心跳保活），不适合高频动态任务（如游戏帧同步、限流令牌刷新）
- 若混合使用：用 timerfd 触发时间轮的 tick（一次 timerfd read 对应一轮 tick），既利用内核精度，又保留时间轮的批量处理能力
- 注意
timerfd_settime的TFD_TIMER_ABSTIME必须传绝对时间，别传相对值——传错就变成 1970 年触发
时间轮真正的复杂点不在算法本身，而在和真实时钟源的对齐方式：是用系统 clock 读数驱动 tick，还是靠 busy-wait 补偿 drift？后者省上下文切换但吃 CPU，前者依赖 clock 稳定性。没人告诉你，CLOCK_MONOTONIC 在某些虚拟机里也会漂移。
