根本原因是每个定时器独占sleep或条件变量导致调度开销放大；时间轮通过空间换时间将到期扫描降至O(1)摊还插入，配合无锁队列、单调时钟与分层设计（如Kafka五层）才能支撑万级并发。
为什么 std::chrono + std::thread 无法撑住万级定时器
直接用 std::this_thread::sleep_for 启一堆线程做定时任务，在 1000+ 并发定时器时就会明显卡顿、唤醒不准、CPU 占用飙升。根本原因不是“线程多”，而是每个定时器都独占一个 sleep 轮询或条件变量等待，系统调度开销和唤醒抖动被放大。时间轮（Timing Wheel）通过空间换时间，把 O(N) 的到期扫描降为 O(1) 摊还插入 + O(M) 到期遍历（M 是当前 tick 到期数），这才是高并发定时器的底层解法。
实操建议：
- 别在每个定时器里 new 一个
std::thread—— 线程创建/销毁成本远高于 tick 处理本身 - 避免用
std::condition_variable::wait_until配合全局锁做集中等待：锁争用会成为瓶颈，尤其在 tick 频率 >10ms 时 - 时间轮必须配合无锁或细粒度锁设计；单个大 mutex 会让所有 tick 操作串行化，吞吐直接腰斩
单层时间轮 vs 分层时间轮：什么时候必须分层
单层时间轮（如 256 槽、每槽 1ms）最多支持 256ms 定时范围，超时任务只能丢弃或降级处理。但线上服务常需支持秒级、分钟级甚至小时级延迟（比如连接空闲 5min 断开、重试间隔 30s）。这时必须用分层时间轮（Hierarchical Timing Wheel），典型如 Kafka 的 5 层设计：毫秒轮、秒轮、分钟轮、小时轮、日轮。
关键参数选择：
立即学习“C++免费学习笔记（深入）”；
- 每层槽位数建议设为 64 或 256 —— 太小导致链表过长，太大浪费内存且 cache 不友好
- 各层 tick 间隔应为整数倍关系（如 1ms → 64ms → 4096ms），避免浮点误差累积导致任务提前或延后触发
- 插入任务时，根据 delay 时间自动路由到对应层级；不要硬编码层级，用
log(delay / base_interval) / log(tier_ratio)动态计算
如何避免定时器任务执行阻塞 tick 主循环
时间轮的 tick 主循环（即推进指针、扫描到期桶）必须轻量。一旦某个定时器回调函数执行耗时 > tick 间隔（比如 tick 是 10ms，但某个 DB 清理任务跑了 120ms），后续所有 tick 就会积压，造成大面积延迟甚至雪崩。
实操方案：
- tick 循环只负责从桶中摘下到期节点，**不执行回调**；把任务对象 push 到一个无锁队列（如
moodycamel::ConcurrentQueue或自研 ring buffer） - 另起 1~N 个工作线程消费该队列，执行用户回调 —— 这样 tick 循环始终稳定在微秒级
- 对回调执行加超时控制：用
std::future::wait_for包裹，超时则记录 warn 日志并丢弃，防止某条坏任务拖垮全局 - 禁止在回调中调用阻塞 I/O（
read(),mysql_query()）、锁竞争激烈的操作（如全局 map 插入）
Linux 上 clock_gettime(CLOCK_MONOTONIC) 是唯一可信时间源
用 std::chrono::steady_clock::now() 在某些旧版 GCC/libstdc++ 上可能退化为 CLOCK_REALTIME，一旦系统时间被 NTP 校正或手动修改，定时器就会乱跳。生产环境必须显式绑定到单调时钟。
正确做法：
- 封装一个
now_ms()函数，内部调用clock_gettime(CLOCK_MONOTONIC, &ts)，返回ts.tv_sec * 1000 + ts.tv_nsec / 1000000 - 初始化时间轮时，用该函数打初始快照；所有 delay 计算、到期判断都基于此差值，彻底与 wall clock 脱钩
- 避免使用
gettimeofday()—— 它不保证单调，且精度通常不如clock_gettime
真正难的不是实现五层时间轮，而是让每个槽位里的任务链表在并发插入/删除时不产生 ABA 问题，也不依赖原子指针的 double-word CAS。多数人卡在这一步就退回了 std::timer_queue —— 其实用 hazard pointer + epoch-based reclamation 就能搞定，但这部分代码超过 200 行，且和业务强耦合，不建议直接抄。
