时间轮调度器需自行实现，因标准库未提供；std::this_thread::sleep_until不适用于高频任务，因其线程开销大、精度低、内存浪费严重；单层轮需O(1)插入与局部扫描，多层轮用于宽时间跨度场景；std::function与std::shared_ptr在高频下性能差，应避免拷贝并优化内存布局。
时间轮调度器在 C++ 中不是“拿来即用”的组件，它必须自己实现——标准库没有 TimerWheel，std::chrono + std::thread 仅提供基础工具，不解决高并发定时任务的插入/到期批量执行/内存局部性问题。
为什么 std::this_thread::sleep_until 不适合高频定时任务
每新增一个任务就起一个线程调 std::this_thread::sleep_until，看似简单，但实际会快速触发系统级瓶颈：线程创建销毁开销大、调度器负载陡增、唤醒精度受 OS 调度粒度限制（Linux 默认 10–15ms），且无法批量处理到期任务。更严重的是，大量休眠线程会占用栈内存（默认 8MB/线程），1000 个任务 ≈ 8GB 内存浪费。
实操建议：
- 仅对低频（≤1 次/秒）、长期存活（≥数分钟）的单次任务考虑该方式
- 必须搭配
std::jthread（C++20）或手动管理std::thread::joinable()防止资源泄漏 - 永远不要在循环中反复
sleep_until做“伪轮询”——CPU 空转 + 时间漂移累积
单层时间轮的插入与到期检查怎么写才不慢
核心是避免每次 tick 都遍历全部槽位。典型单层时间轮用 std::vector<:list>>，槽位数固定（如 64 或 256），但关键在：插入时必须 O(1)，到期扫描必须只扫当前槽，且不能锁整个轮子。
常见错误现象：operator[] 访问 vector 未预分配导致频繁 realloc；用 std::map 存槽位（引入 logN 开销）；到期时用 for (auto& t : bucket) { t(); } 却没把 task 移出 list，导致重复执行。
实操建议：
- 初始化时用
slots_.resize(N)预分配，禁止运行时 resize - 插入任务：计算
hash = (expire_time - base_time) % N，直接 push_back 到slots_[hash] - tick 函数内：只清空并遍历
slots_[current_slot_]，执行前用std::move转移回调，再clear()整个 list - 用
std::atomic管理current_slot_，读写无需锁（前提是单生产者 tick 线程）
多层时间轮（hierarchical timing wheel）什么时候必须上
单层轮只适合时间跨度小、精度要求一致的场景（比如全部任务在 0–60s 内到期）。一旦要支持从 10ms 到 1小时 的任务共存，单层轮要么槽太多（内存爆炸），要么槽太少（精度丢失）。多层轮（如 3 层：毫秒/秒/分钟）本质是分治——短任务走底层，长任务先挂高层，逐层降级。
性能影响明显：插入复杂度从 O(1) 变为 O(L)（L=层数），但内存从 O(T/Δ) 降到 O(L×N)，T 是最大时间跨度，Δ 是最小精度。
实操建议：
- 第 0 层（毫秒级）：64 槽，每槽代表 10ms，覆盖 0–640ms
- 第 1 层（秒级）：60 槽，每槽代表 1s，覆盖 640ms–64s；当第 0 层一轮跑完（64×10ms=640ms），将第 1 层对应槽的任务“倒入”第 0 层
- 第 2 层（分钟级）同理，但注意：任务降级时需重新计算在下层的槽位偏移，不是简单挪过去
- 所有层共享同一 base time，用
std::chrono::steady_clock::now()避免系统时间跳变干扰
std::function + std::shared_ptr 会导致性能断崖？
是的。在高频插入（≥10k/s）场景下，std::function 构造 + std::shared_ptr 引用计数原子操作会吃掉 20%+ CPU 时间。这不是理论推测——perf record 显示 __gnu_cxx::__exchange_and_add_dispatch 和 std::function 的内部 malloc 占主导。
可替代方案有限但有效：
- 用裸函数指针 +
void*用户数据（适用于无状态回调或自管理生命周期的对象） - 用对象池预分配
Task结构体，内部用 union 存不同签名的函数指针，避免 new/delete - 若必须用
std::function，至少用std::function移动构造，禁止拷贝&& - 绝对不要在
Task里存std::shared_ptr<:string>这类重型对象——改用 string_view 或 const char*
真正难的不是写出能跑的轮子，而是让 add_task() 和 tick() 在 100 万任务下仍保持 sub-microsecond 均值延迟。这要求你亲手控制内存布局（cache line 对齐槽位）、规避 false sharing（每个 slot 用 alignas(64)）、以及接受“不支持动态调整轮大小”这个设计约束——可伸缩性在这里是敌人，确定性才是朋友。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
