普通时间轮在高并发下卡住是因为任务同槽串行处理且无优先级区分，形成“单门拥堵”；解决方案是双层时间轮解耦时间与优先级维度，外层分发、内层优先队列调度，并采用slot粒度锁和单调时钟校准。
为什么普通时间轮在高并发定时任务下会卡住
因为标准时间轮（如单层哈希时间轮）的 tick 精度和槽位数固定，当大量任务集中在同一 slot 触发时，process_wheel_slot() 会串行遍历链表，形成热点。更关键的是，它不区分任务优先级——紧急的心跳续期和低优的日志刷盘混在同一链表里，高优任务被迫等待。
真正的瓶颈不在“轮子转得慢”，而在“所有任务挤一扇门”。解决思路不是加锁提速，而是分门别类、错峰通行。
用双层时间轮 + 优先级队列组合实现 O(1) 插入 + 分级调度
核心是把「时间维度」和「优先级维度」解耦：外层时间轮负责粗粒度到期分发（毫秒/秒级精度），每个 slot 不存任务本身，而存一个 std::priority_queue；内层按优先级排序，保证每次 pop() 拿到当前 slot 中最高优任务。
- 外层轮大小设为 256，步进单位
TICK_MS = 10，覆盖 2.56 秒窗口，足够应对大多数短周期任务 - 每个 slot 的优先级队列使用自定义比较器：
task->priority越小越先执行（0=最高） - 插入时计算绝对到期时间戳，映射到外层轮索引：
slot_idx = (expire_time_ms / TICK_MS) % WHEEL_SIZE - tick 线程每
TICK_MS执行一次：advance_and_drain_current_slot()，只 pop 当前 slot 队列顶部若干任务（避免单次耗时过长）
多线程安全的关键不是锁整个轮子，而是锁 slot 粒度
如果对整个时间轮加 std::mutex，插入和 tick 会互斥，吞吐直接归零。正确做法是给每个 slot 配独立的 std::shared_mutex（C++17）：
- 插入任务时只锁对应
slots[slot_idx].mutex，写入其priority_queue - tick 线程读取当前 slot 时用
shared_lock，允许并发读；真正执行任务回调前升级为unique_lock清空该 slot 队列 - 注意：不能用
std::queue替代std::priority_queue，后者不支持迭代器遍历，必须反复top()/pop() - 避免内存泄漏：任务对象建议用
std::shared_ptr<task></task>管理，确保 tick 线程持有引用期间不会析构
实际压测中容易被忽略的三个细节
很多实现跑单元测试没问题，一上生产就丢任务或延迟飙升，问题往往藏在这几处：
-
std::priority_queue默认底层容器是std::vector，但频繁push/pop会导致内存重分配——改用std::deque作为容器模板参数，减少锁持有时间 - tick 线程用
std::this_thread::sleep_for()控制节奏时，若系统负载高，实际 sleep 可能严重超时；应改用单调时钟 + 时间差校准，例如记录上次 tick 时间戳，下次检查now - last_tick >= TICK_MS - 任务回调函数若抛异常未捕获，会杀死整个 tick 线程；务必在
execute_task()外层包try/catch(...)，记录错误日志并继续处理下一个任务
最麻烦的其实是时间漂移累积——哪怕每次只慢 0.1ms，10 万次 tick 就偏差 10 秒。上线前一定用 clock_gettime(CLOCK_MONOTONIC, &ts) 做真机时钟比对。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
