时间轮通过环形数组实现O(1)定时操作，核心是按tick推进当前槽并清空，避免全量扫描；需用整数除法计算槽位、分段加锁保障线程安全，并以剩余时间迁移多层轮定时器。
为什么直接用 std::chrono + std::thread 做定时器扛不住高并发
单个线程轮询 std::chrono::steady_clock::now() 判断超时，或为每个定时任务开一个线程，这两种做法在 10k+ 定时任务、毫秒级精度下会迅速崩：前者轮询频率高导致 CPU 空转，后者线程数爆炸、上下文切换开销压垮系统。时间轮的核心价值不是“更准”，而是把 O(N) 插入/删除/推进 降为 O(1)，靠空间换时间——你得接受它有精度粒度（比如 10ms 一格），但换来的是万级定时器常数级操作。
std::vector 实现单层时间轮要注意什么
最简时间轮就是个环形数组：std::vector<:list>>> wheel，索引对数组长度取模。关键陷阱在「推进逻辑」：不能每 tick 都遍历全部槽位，而应只推进当前槽（current_slot = (current_slot + 1) % wheel.size()），再清空该槽里所有定时器。否则 tick 频率稍高（如 1ms）就退化成 O(N) 扫描。
- 槽位数建议设为 2 的幂（如 512），用位运算替代取模：
current_slot = (current_slot + 1) & (wheel.size() - 1) - 每个槽里存
std::shared_ptr而非裸指针，避免定时器回调中 self-destruct 导致悬垂指针 - 插入时计算到期槽位：若当前时间为
t，定时器延时delay_ms，则槽位 =(t / tick_ms + delay_ms / tick_ms) % wheel.size()—— 注意这里必须用整数除法，且tick_ms是你设定的最小时间粒度（如 10）
多层时间轮（Hierarchical Timing Wheel）怎么避免跨层误触发
单层轮解决不了长周期定时器（比如 1 小时后执行）—— 槽位数太多浪费内存，或者精度暴跌。多层轮（如 3 层：毫秒层、秒层、分钟层）是标准解法，但容易在「降级迁移」时出错：当某定时器在高层轮（如秒轮）中到期，要把它重新插入低层轮（毫秒轮），此时必须用 剩余时间 计算新槽位，而非原始延时。
- 错误写法：
insert_to_millisecond_wheel(original_delay)→ 会导致提前触发 - 正确写法：先算出当前已过时间
elapsed，再插insert_to_millisecond_wheel(original_delay - elapsed) - 各层轮的 tick 时间需严格倍数关系（如毫秒轮 10ms/tick、秒轮 1000ms/tick、分钟轮 60000ms/tick），否则迁移时余数计算失准
- 高层轮的槽位触发后，必须清空该槽并立即迁移子定时器，不能延迟到下次 tick —— 否则会漏掉紧邻的多个短延时任务
如何让时间轮线程安全又不锁整个轮结构
服务端定时器必然被多线程调用（网络 IO 线程注册超时、业务线程取消任务）。全局锁 std::mutex 会成为瓶颈。实际做法是分段加锁：每个槽位配一个独立 std::mutex，插入时只锁目标槽，执行回调时锁整个槽再遍历 list。这样并发插入互不影响，只有同一槽位的插入/执行才竞争。
- 别用
std::shared_mutex：读多写少场景看似合适，但定时器执行是写操作（清空 list），且 C++17 前shared_mutex性能未必优于分段互斥量 - 回调函数内禁止调用
cancel()或reset()同一个定时器 —— 这会引发双重释放，应在回调外通过消息队列异步处理取消请求 - 考虑用
std::atomic统计总定时器数，但注意它不保证 list 操作原子性，仅用于监控，不可用于同步逻辑
真正难的不是实现轮子，而是确定 tick 精度与槽位数的平衡点：太细（1ms/tick）导致轮太大，太粗（100ms/tick）导致业务超时抖动明显。通常从 10ms 开始压测，观察 GC 延迟和 CPU 占用拐点。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
