时间轮调度器不能仅用std::chrono+std::thread轮询实现，因其CPU浪费、亚毫秒精度缺失、唤醒延迟高；高性能实现须依赖timerfd+epoll等系统机制，并与I/O多路复用耦合，配合无锁分段桶、预分配内存和位运算索引优化。
时间轮调度器为什么不能直接用 std::chrono + std::thread 轮询实现
因为轮询会浪费 CPU，且无法做到亚毫秒级精度和低延迟唤醒。真正高性能的时间轮必须依赖系统级定时机制（如 Linux 的 timerfd_create）或高精度事件循环（如 epoll_wait 带超时），否则在 10k+ 定时任务下，单纯 sleep + 遍历会迅速退化为 O(n) 检查，吞吐暴跌。
常见错误是把「时间轮」当成一个带哈希桶的 vector，却忽略它必须和 I/O 多路复用深度耦合——否则无法在不阻塞主线程的前提下响应到期任务。
-
std::this_thread::sleep_for无法被外部中断，导致新任务插入延迟不可控 - 纯内存轮询无法触发内核级唤醒，实际唤醒误差常达 10~50ms（尤其在负载高时）
- 未对齐 tick 粒度（如设为 10ms，但任务要求 3ms 精度）会导致批量漂移累积
如何用 timerfd 实现单层时间轮的 tick 驱动
Linux 下最轻量、最可控的方式是用 timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK) 创建一个可读 fd，然后用 epoll_ctl 把它加入事件循环。每次 tick 到期，内核自动往 fd 写入 uint64_t 计数，read() 一次即可获知过了几个 tick。
关键不是“轮子转”，而是让轮子转得准、转得省、转得可干预：
立即学习“C++免费学习笔记（深入）”；
- tick 间隔必须是固定整数毫秒（如 1ms/5ms/10ms），避免浮点累积误差
- 初始化时调用
timerfd_settime(..., TFD_TIMER_ABSTIME)设置绝对起始时间，防止首次 delay 不稳定 - 每次
read(fd, &exp, sizeof(exp))后，必须处理 exp 次 tick —— 因为可能因调度延迟导致多次到期未读 - 不要在
read后立刻重设 timerfd；应基于当前 monotonic 时间 + tick * exp 计算下次到期点再 set
std::vector<:list>></:list> 桶结构在高并发插入时为何容易卡顿
问题不在数据结构本身，而在缺乏无锁设计和桶索引计算方式。当多个线程同时插入任务，若都用 hash(time) % bucket_size 计算桶号，高频任务集中在少数桶（比如所有 100ms 后任务全挤进第 10 个桶），导致链表过长、插入退化为 O(n)，且 std::list 的节点分配会触发频繁 malloc。
更糟的是：如果插入逻辑里有锁保护整个 vector，那所有线程都会争抢同一把 mutex。
- 改用分段锁：每个桶配独立
std::shared_mutex，写时只锁对应桶 - 桶索引改用
(time_point.time_since_epoch().count() / tick_ns) & (bucket_size - 1)，前提是 bucket_size 是 2 的幂，位运算替代取模 - 任务节点预分配：用
boost::object_pool或自定义 arena 分配器，避免每次 new/delete - 插入前先检查是否已过期（即目标桶 index
多级时间轮（hierarchical timing wheel）真的必要吗
90% 的业务场景不需要。多级轮（如 256 × 256）是为了支持超长延时（小时/天级）且保持内存占用恒定，但它带来显著复杂度：跨级溢出传播、反向查找困难、取消任务需遍历多层、调试时难以 trace 到底在哪一层。
如果你的任务最大延迟 ≤ 1 小时，单层 8192 桶 + tick=50ms 已覆盖 409.6 秒，足够用。真需要小时级，不如用单独的「延迟队列」+ 「后台扫描线程」，反而更清晰、易测、易 cancel。
容易被忽略的一点：std::chrono::steady_clock 在某些虚拟化环境（如 AWS Nitro）下存在微小 drift，多级轮的 long-term tick 累积会让 drift 放大，最终出现任务提前或漏触发——这不是代码 bug，是硬件时钟特性。
