std::chrono+std::thread轮询不可行，因其唤醒精度差（Linux下常偏差10–15ms）、CPU空转、无法支持O(1)插入/删除/到期检测，且高并发下线程开销指数级增长。
时间轮调度器为什么不能直接用 std::chrono + std::thread 轮询
因为轮询本身就有精度损耗和 CPU 空转问题，尤其在毫秒级调度下，std::this_thread::sleep_for 实际唤醒时间可能偏差 10–15ms（Windows 默认时钟粒度），且无法应对大量定时任务的插入/删除高频操作。真实场景中，你不是要“每隔 10ms 查一次”，而是要“在 127ms 后精准触发某回调”——这要求调度器具备 O(1) 插入、O(1) 到期检测、O(1) 删除能力，而轮询模型天然做不到。
常见错误现象：std::chrono::steady_clock::now() 在循环里反复调用导致 cache line 频繁失效；多个 std::thread 竞争同一任务队列引发锁争用；任务延迟累积（比如第 100 次 sleep 偏差叠加后整体漂移 > 1s）。
- 别把
std::this_thread::sleep_for当调度核心，它只是底层等待手段 - 所有时间计算必须基于
steady_clock，禁止用system_clock（会受系统时间调整影响） - 单线程驱动 + 无锁环形缓冲区（如
boost::lockfree::spsc_queue）比多线程轮询更可控
哈希时间轮（Hashed Timing Wheel）如何避免层级跳变抖动
经典分层时间轮（如 Kafka 的 5 层）在 tick 推进时，高阶轮需批量 rehash 下挂任务，造成偶发性毛刺。而哈希时间轮把到期时间 t 映射到桶 t % N，每个桶内用链表或小顶堆维护任务，靠单次 tick 推进只检查一个桶——没有跨层迁移，也没有批量搬迁开销。
关键点在于：桶数 N 必须是 2 的幂（便于编译期优化取模为位运算），且初始桶大小要覆盖常用周期。例如，若 90% 的任务在 1s 内到期，设 N = 1024，基础 tick = 1ms，则单轮覆盖 1.024s，足够平滑。
立即学习“C++免费学习笔记（深入）”；
- 任务插入时计算
bucket_idx = (expire_time_ms - base_time_ms) & (N - 1)，不是% N - 每个桶内任务按绝对到期时间排序，用 intrusive list（免内存分配）比
std::list更快 - 不维护“当前 tick 值”，而是每次推进时用
steady_clock::now()动态算偏移，避免 tick 计数器溢出或 drift
std::atomic<uint64_t></uint64_t> 作时间基线 vs clock_gettime(CLOCK_MONOTONIC)
Linux 下 std::chrono::steady_clock 底层通常就是 CLOCK_MONOTONIC，但 C++ 标准未规定其实现细节。某些嵌入式 STL（如 newlib）的 steady_clock::now() 可能走低精度 fallback 路径。直接调用 clock_gettime 能绕过 ABI 层，拿到纳秒级原始值。
但代价是可移植性下降，且需要手动处理 timespec → uint64_t 转换。实操建议：在 x86_64 Linux 生产环境用 clock_gettime；其他平台（Windows/macOS）仍用 steady_clock，并加编译期断言确保其 period::den ≥ 1'000'000（即支持微秒级）。
- Windows 上不要用
QueryPerformanceCounter手动封装——steady_clock在 VS2015+ 已正确映射到它 - 避免在时间计算中混用不同 clock：
steady_clock::now()和system_clock::now()不能相减 - 所有时间差一律转成
uint64_t微秒单位存储，避免duration_cast多次转换损耗
任务取消与析构安全：为什么 std::shared_ptr 不够用
当用户持有任务 handle 并调用 cancel() 时，调度器必须保证：1）该任务不再被触发；2）其回调对象在最后一次访问后才析构；3）不引发 ABA 或 use-after-free。仅靠 std::shared_ptr 无法解决第 1 点——因为任务已入桶，取消只是标记，桶扫描线程仍可能取出并执行。
正确做法是引入状态原子变量：std::atomic<taskstate> state{TaskState::PENDING}</taskstate>，其中 TaskState 枚举含 PENDING/CANCELLED/FIRED。每次执行前先 compare_exchange PENDING → FIRED，失败则跳过。这样 cancel 是立即生效的，且无锁。
- 回调函数体内禁止再调用本调度器的任何方法（防止递归锁或重入破坏桶结构）
- 任务对象内存生命周期由 intrusive refcount 控制，而非
shared_ptr——避免虚表和控制块额外开销 - cancel() 后立即调用
state.exchange(CANCELLED)，而不是先查再改，防止竞态窗口
真正难的不是实现 ticking，而是让 cancel 语义在并发、重入、异常抛出等边界下依然可靠。很多开源实现在这里留坑：比如只置标志位却不阻断执行路径，或者用 mutex 保护单个任务状态导致全局性能瓶颈。
