std::chrono+std::thread无法扛住万级定时任务，因线程开销大、调度压力剧增，轮询精度低且不支持动态增删；时间轮通过环形数组实现O(1)插入/触发，以空间换时间提升 scalability。
为什么 std::chrono + std::thread 无法扛住万级定时任务
直接用 std::this_thread::sleep_for 轮询或为每个定时任务起一个线程，在任务数超过几百后就会明显卡顿甚至崩溃。根本原因是：线程创建/销毁开销大，系统调度压力陡增；而轮询 sleep 模式下，精度和响应延迟不可控，且无法动态增删任务。
时间轮（Timing Wheel）本质是空间换时间：把时间轴“折叠”成固定大小的环形数组，每个槽位挂一个任务链表，指针每 tick 前进一步——插入、删除、触发都稳定 O(1)，不随任务总数增长。
- 单层时间轮适合短周期高频任务（如 10ms~5s），槽位数通常取 256 或 512，避免 cache line false sharing
- 若需支持小时级延迟，必须用多级时间轮（如 Kafka 的层级设计），但绝大多数服务端场景用单层 + 两级哈希桶就足够
- 注意
std::chrono::steady_clock是唯一可靠时钟源，system_clock可能被 NTP 调整导致跳变
如何用 std::array + std::vector 实现无锁单层时间轮
核心结构是 std::array<:vector>, 256></:vector>，其中 Task 至少包含 expire_time（绝对时间点）、callback（std::function<void></void>）、id（用于取消）。关键不在“轮子”，而在怎么把任务映射到槽位并处理溢出。
- 槽位索引 =
(expire_time / tick_ms) % wheel_size，tick_ms 一般设为 10 或 50（太小导致频繁 tick，太大降低精度） - 同一槽位内任务必须按
expire_time排序，否则提前触发会漏掉更早到期的任务；推荐插入时二分查找位置，而非事后排序 - 不要在 tick 线程里直接执行 callback——尤其当 callback 可能阻塞或抛异常时。应把待执行任务 move 出来，再在 worker 线程池中 dispatch
- 取消任务靠
id查找并 erase，但 vector erase 是 O(N)；实际可改用std::list或带 freelist 的自定义池，不过多数场景下用std::vector+ 标记删除（lazy cleanup）更缓存友好
std::atomic + memory_order_relaxed 足够支撑 tick 指针推进吗
时间轮的 tick 指针（当前槽位索引）只需单写多读，且业务逻辑允许“最多晚 1 个 tick 触发”，因此 std::atomic<uint8_t></uint8_t> 配 memory_order_relaxed 完全够用，比 acquire/release 快 3~5 倍（实测 L1 cache miss 减少）。
立即学习“C++免费学习笔记（深入）”；
- tick 线程用
while(true) { ptr.fetch_add(1, std::memory_order_relaxed); std::this_thread::sleep_for(10ms); }即可，无需锁或 CAS 循环 - 插入任务时读取
ptr.load(std::memory_order_relaxed)计算槽位，即使读到旧值也只影响最多 1 个 tick 的偏差，符合设计预期 - 切忌对
ptr使用memory_order_seq_cst——它会强制全局内存栅栏，在多核下显著拖慢 tick 频率
为什么不能直接用 boost::asio::steady_timer 或 libuv 的 timer
这些库的定时器底层仍是红黑树或最小堆，插入/删除复杂度 O(log N)。当并发任务达 10k+ 且每秒新增/取消数百个时，堆调整开销会吃掉大量 CPU，且难以做批量过期扫描优化。
-
boost::asio::steady_timer单实例只能管理一个定时器，要管多个就得用basic_waitable_timer数组，内存碎片和调度开销反而更大 - libuv 的
uv_timer_t虽支持重复，但所有 timer 共享一个堆，高负载下 heapify 成为瓶颈（perf record 显示uv__timer_cmp占 CPU 15%+） - 时间轮天然支持批量扫描：每次 tick 只需遍历一个 vector，cache 局部性极好；而堆每次都要从根往下 sift，随机访存严重
真正难的不是实现轮子，而是决定哪些任务该进时间轮、哪些该走 event loop 原生 timer——比如连接超时放时间轮，HTTP 请求重试放 asio timer，这种混合策略比纯时间轮更稳。另外，时间轮不解决回调执行耗时问题，得配合限流和异步化，否则 tick 线程一卡，整个调度就积压。
