std::chrono + std::thread 不适合高并发定时任务，因其每次 sleep_for 都阻塞线程，唤醒精度受系统调度器限制（Linux 默认时钟粒度 1–15ms），大量短周期定时器导致频繁挂起/唤醒、上下文切换开销暴涨，且无法批量到期处理、O(1) 增删或复用线程资源。
为什么 std::chrono + std::thread 不适合高并发定时任务
因为每次 std::this_thread::sleep_for 都要阻塞线程，而唤醒精度受系统调度器影响（Linux 默认时钟粒度 1–15ms），大量短周期定时器会触发频繁的线程挂起/唤醒，CPU 上下文切换开销暴涨。更关键的是：无法批量到期处理、无法 O(1) 插入/删除、无法复用线程资源。
真实场景中，当定时器数量 > 10k 且平均超时时间 std::thread 方案的吞吐会断崖式下跌，延迟毛刺明显升高。
- 避免在循环里调用
sleep_for做“轮询式”定时 —— 这本质是 busy-wait 的变种，浪费 CPU - 不要为每个定时器分配独立线程 —— 线程栈内存和内核调度成本远高于 timerfd 或时间轮
- 若必须用标准库，至少用
std::condition_variable::wait_until配合单个调度线程，但仍是 O(n) 扫描到期队列
如何用 8 层哈希桶实现分层时间轮（Hierarchical Timing Wheel）
单层时间轮（如 Linux kernel 的 timer_list）只支持固定精度和有限时间范围；高并发场景必须分层。典型设计是 4 级 64 桶（每级 64 个槽），但 C++ 实现时更推荐 8 层 × 256 桶：前 4 层覆盖毫秒到秒级（精度 1ms/4ms/16ms/64ms），后 4 层覆盖分钟到天级（精度 4s/16s/64s/256s），总时间跨度达 ~18 小时，且插入/删除均为 O(1)。
核心在于每个定时器节点只存于**一层**的某个桶中，其层级由剩余超时时间决定：level = min(7, floor(log2(timeout_ms / base_granularity)))，其中 base_granularity = 1（单位 ms）。这样既避免跨层跳转，又保证长周期定时器不挤占高频桶。
立即学习“C++免费学习笔记（深入）”；
- 每层桶使用
std::vector<:list>></:list>，而非std::unordered_map—— 避免哈希冲突导致的链表退化 - 所有定时器节点内存必须预分配（如用
std::deque<timernode></timernode>池化），禁止运行时 new/delete - 层级索引计算务必用位运算替代
log2：例如level = (timeout_ms == 0) ? 0 : 63 - __builtin_clzll(timeout_ms)（GCC/Clang）
优先级怎么嵌进时间轮里而不破坏 O(1) 性能
不能在每个桶里再套一个堆（如 std::priority_queue）—— 那会让到期遍历变成 O(k log k)，k 是桶内定时器数；也不能把优先级作为时间轮的第 9 层 —— 时间轮本身不处理“同时间点谁先触发”的问题。
正确做法是：**时间轮只负责“何时触发”，优先级交给就绪队列**。当某桶到期时，把所有节点按优先级插入一个无锁多生产者单消费者队列（如 moodycamel::ConcurrentQueue），由工作线程从该队列取任务执行。这样时间轮仍保持 O(1) 插删，优先级调度下沉到执行层。
- 优先级值建议用 int（-128 ~ 127），避免浮点比较；升序表示“越小越先执行”
- 若需严格 FIFO 同优先级，队列元素结构体中加
uint64_t insert_seq（原子递增） - 切勿在时间轮 tick 回调里直接执行用户回调函数 —— 可能阻塞轮子推进，应只做入队操作
Linux 下如何用 timerfd_settime 替代 while(sleep) 做主循环驱动
用户态时间轮需要精准、可唤醒、不阻塞的时钟源。timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK) 创建的 fd，配合 epoll_wait，能实现零忙等、纳秒级精度（实际受限于内核 HZ）、且被信号中断时仍可靠。
关键点：设置 it_interval 为 0 表示只触发一次，每次 tick 后重新调用 timerfd_settime 设定下一个 tick 时间（比如当前时间 + 1ms），避免累积误差。同时用 read() 读取 uint64_t 计数值，确认是否真的到期（防止 spurious wakeup）。
- 必须设
TFD_CLOEXEC，否则 fork 后子进程会继承该 fd 导致重复触发 - epoll event 必须用
EPOLLIN | EPOLLET（边缘触发），否则可能漏事件 - 不要用
clock_gettime在 tick 回调里反复获取当前时间 —— 改用传入的已知 tick 时间戳做桶索引计算
时间轮的真正难点不在结构设计，而在「桶迁移」和「跨层重调度」的边界条件：比如一个 65ms 定时器在第 2 层（16ms 精度）到期时，剩余 1ms，此时必须把它降级到第 0 层（1ms 精度）对应桶，而不是留在原层等待下一轮扫描。这个逻辑一旦出错，就会出现定时器漂移或丢失。
