单线程时间轮核心是O(1)插入/删除与摊还O(1)tick推进，vector+list组合最简可靠：vector支持槽位随机访问，list支持无拷贝增删，steady_clock避免NTP导致错乱。
单线程时间轮（Hashed Wheel Timer）在 C++ 中能轻松支撑每秒数万定时任务，但直接手写容易掉进指针悬挂、时钟漂移、桶迁移竞争这三类坑——关键不在轮子怎么转，而在「槽位生命周期」和「tick 精度边界」怎么管。
为什么 std::chrono::steady_clock + vector> 是最简可靠起点
别一上来就上 lock-free queue 或 ring buffer。时间轮核心诉求是 O(1) 插入/删除 + 摊还 O(1) tick 推进，vector + list 组合天然匹配：
-
vector按槽位索引随机访问快，resize 成本摊到整个轮周期里几乎可忽略 -
list<Task*>支持无拷贝插入/擦除，避免Task对象移动导致的回调地址失效 -
steady_clock避免系统时间被 NTP 调整导致的 tick 错乱，system_clock在生产环境会丢任务
错误示范：vector<unique_ptr<Task>> —— tick 时遍历销毁会导致内存抖动；deque 当作环形缓冲 —— 迭代器在 resize 后可能失效，且不支持 O(1) 槽位跳转。
如何安全处理「任务提前触发」和「超长延迟任务」
真实场景中，用户调用 schedule(delay_ms, cb) 时，delay 可能远超一轮周期（比如设了 2 小时后执行），也可能极短（1ms）。必须分层处理：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 延迟 ≤ 一轮周期（如 60s）→ 直接映射到对应槽位
bucket[(now + delay) % N] - 延迟 > 一轮周期 → 先降级为「粗粒度轮」：把大 delay 折算成「轮数 + 偏移槽」，存入一个
multimap<int64_t, Task*>（key = 到期轮数），每轮 tick 时查一次该 map - 绝对禁止把 1ms 任务塞进 100ms 槽位精度的轮里——它会在 100ms 后才执行，误差超标。需单独维护一个
priority_queue<Task*, vector<Task*>, CompareByDeadline>处理 sub-tick 级任务
典型错误：if (delay < tick_ms) schedule_immediately() —— 主线程立刻调用回调，但此时用户代码可能正持有锁或处于析构中，引发重入或 use-after-free。
tick 线程与任务回调线程分离时的内存安全红线
如果 tick 在 dedicated thread 执行，而回调在业务线程跑（比如 IO 线程池），那么 Task 对象的释放时机必须严格约定：
- tick 线程只负责从 bucket 中摘下
Task*，**不 delete，不 reset shared_ptr** - 回调执行完后，由业务方显式调用
task->done()或通过 RAII wrapper 自动标记完成 - 使用
std::atomic<bool> Task::active_防止重复执行：tick 线程摘下前先exchange(true)，回调入口再 check，避免信号丢失或双触发
最容易忽略的是：任务回调里调用了 schedule() 自身——若没做递归保护，可能在遍历当前 bucket 时又往里面 push_back，导致迭代器失效。解决方式不是加锁，而是把新增任务暂存在 thread_local vector<Task*>，tick 循环结束后统一 merge。
Linux 下 clock_gettime(CLOCK_MONOTONIC, ...) 比 std::chrono 更稳吗？
在 glibc 2.17+ 和主流内核上，std::chrono::steady_clock::now() 底层就是 clock_gettime(CLOCK_MONOTONIC, ...)，二者行为一致。但要注意：
- 不要用
CLOCK_MONOTONIC_RAW：它不补偿硬件时钟漂移，长期运行误差可达毫秒级 - 避免高频调用
now()：每次系统调用有开销。应在每次 tick 开始时缓存一次now，所有槽位计算复用该值 - 实测发现：在某些云主机（如 AWS c5 实例）上，
steady_clock::now()的 std::nanoseconds 构造比 rawtimespec多 3~5ns，对微秒级调度无影响，但别在 tight loop 里反复构造time_point
真正影响精度的从来不是时钟源，而是 tick 线程的调度延迟——如果用 SCHED_FIFO 绑核，能把 jitter 控制在 ±2μs 内；默认 SCHED_OTHER 下，一次 tick 可能被推迟几十微秒，这时再纠结纳秒级时钟没意义。
