根本问题在于O(N)时间复杂度的全量扫描，而非精度；分层时间轮通过分桶+懒惰降级实现insert/cancel平均O(1)，tick仅处理当前桶任务，结合intrusive list与CLOCK_MONOTONIC可支撑万级定时任务。
为什么 std::chrono + std::thread 无法撑住万级定时任务
直接用 std::this_thread::sleep_for 或轮询 std::chrono::steady_clock::now() 做定时，每新增一个任务就起一个线程或加一次条件变量唤醒，任务量一过千，CPU 负载和调度开销就指数上升。根本问题不在“精度”，而在“时间复杂度”——每次 tick 都要遍历全部任务判断是否到期，O(N) 检查无法横向扩展。
真实瓶颈常出现在：服务端需维护数万连接的心跳超时、MQTT 客户端批量 QoS1 消息重发、游戏服务器中大量技能冷却/ buff 持续时间管理。这些场景共同点是：任务生命周期长、创建销毁频繁、触发时间离散但总量大。
- 单 tick 扫描所有任务 → 即使只有 0.1% 到期，也要遍历 10k 元素
- 插入/删除操作若非 O(1) → 每次新增延迟任务都要排序或查找插入位置
- 多线程安全靠锁保护全局任务容器 → 高并发下
std::mutex成为热点
时间轮不是“轮子”，是分层哈希桶 + 懒惰推进
经典分层时间轮（Hierarchical Timing Wheel）本质是把时间轴按精度分段切片：底层桶粒度小（如 10ms），容量有限（如 256 桶）；上层桶代表更大时间跨度（如 1s、1m），靠“降级”机制自动迁移未到期任务。关键不是“转圈”，而是避免全量扫描。
真正高性能的实现必须满足三点：insert 和 cancel 平均 O(1)，tick 推进只处理当前桶内任务，且无临界区锁竞争。
立即学习“C++免费学习笔记（深入）”；
- 每个任务携带唯一
id和原始到期时间戳（绝对值），插入时计算所属桶索引，不依赖排序 - 底层轮每 tick 只 pop 当前桶链表，已到期任务立即执行；未到期任务若跨轮则“降级”到上层轮对应桶
- 取消任务不真删节点，而设
is_canceled = true标志位，执行前检查，避免锁内遍历删除 - 各层轮独立推进，上层轮每转一圈才驱动下层轮走一轮 —— 这是时间压缩的核心
std::shared_ptr + intrusive list 是零拷贝的关键
任务对象若频繁构造析构，内存分配器压力巨大。用 std::make_shared 预分配对象+引用计数，再配合侵入式链表（intrusive list）把任务自身作为链表节点，可彻底消除插入/删除时的内存搬运和额外指针间接跳转。
示例结构体定义必须包含链表钩子：
struct TimerTask {
uint64_t id;
uint64_t expire_at; // 绝对时间戳（ns）
std::function<void()> cb;
bool is_canceled{false};
// 侵入式链表节点（不额外 new）
boost::intrusive::list_member_hook<> hook;
};
- 使用
boost::intrusive::list而非std::list：节点内存与任务对象物理连续，缓存友好 -
hook不占额外空间，复用对象末尾 padding；插入仅改指针，无内存分配 - 回调函数捕获外部变量时，务必用
std::move转移所有权，防止隐式拷贝闭包 - 避免在回调里调用
schedule()自身 —— 可能导致重入桶推进逻辑，需用 post 到 io_context 或队列延后
Linux 上 clock_gettime(CLOCK_MONOTONIC, ...) 是唯一可靠时间源
别用 gettimeofday() 或 std::chrono::system_clock：前者可能因 NTP 调整倒退，后者受系统时间修改影响，会导致任务提前/漏触发。C++20 的 std::chrono::utc_clock 仍不适用于此场景。
- 初始化时调用一次
clock_gettime(CLOCK_MONOTONIC, &ts)获取基准，后续所有expire_at都基于该起点偏移计算 - tick 推进间隔不能硬编码 sleep，必须用
clock_gettime实测上一 tick 到现在的实际耗时，动态补偿 drift - 若业务允许误差 ±5ms，可每 10ms tick 一次；若需 sub-ms 精度，需绑定 CPU 核 + 设置 SCHED_FIFO 优先级，但代价是牺牲系统其他进程响应
- 注意
CLOCK_MONOTONIC_RAW虽不受 NTP 频率调整影响，但硬件时钟漂移更大，一般场景反不如CLOCK_MONOTONIC
分层时间轮的复杂度不在代码行数，而在“降级时机”的判定边界和跨层任务迁移的一致性。哪怕只错一个桶索引计算，就会让任务永远沉底不触发 —— 这类 bug 很难复现，必须靠带时间戳的单元测试覆盖所有轮换边界条件。
