普通时间轮在高并发下撑不住，因其固定槽位需遍历链表，万级任务同毫秒到期会导致tick卡主线程、CPU飙升；分层时间轮+每槽小顶堆可解：时间轮粗筛时间，堆细排优先级，配合shared_mutex锁桶、steady_clock相对时间及2的幂槽位设计保障高吞吐不丢任务。
为什么普通时间轮在高并发定时任务里撑不住
因为标准时间轮（如单层哈希时间轮）的槽位固定，到期任务需要遍历整个槽链表，当每秒有上万任务到期、且大量任务集中在同一毫秒级时间点时，tick() 函数会卡住主线程或工作线程，CPU 突增、延迟飙升。优先级不是加个 std::priority_queue 就能解决的——它破坏了时间轮 O(1) 插入和均摊 O(1) 到期扫描的特性。
用分层时间轮 + 每槽内小顶堆实现优先级调度
核心思路是：时间轮负责“粗筛时间”，堆负责“细排顺序”。不把所有任务塞进一个堆，而是每个时间槽（bucket）维护一个 std::priority_queue，比较函数按任务的 priority 和 id（防同优先级饥饿）升序排列。
- 时间轮仍用 4 层结构（毫秒/秒/分钟/小时），但第 0 层（最小粒度层）每个 bucket 存
std::priority_queue<Task*, std::vector<Task*>, TaskCompare> -
Task结构体必须包含expire_time_ms（绝对时间戳）、priority（越小越先执行）、id（单调递增序列号） - 插入时先算出归属哪一层哪一槽，只在最底层槽中 push 堆；上层槽仅用于推进指针，不存任务
-
tick()每次只从当前槽 pop 堆顶（若堆非空），直到堆空或堆顶任务未到期（说明有更高优先级任务插队进来了，但时间未到）
std::priority_queue 在多线程环境下必须加锁，但别锁整轮
直接对整个时间轮加互斥锁会导致 add_task() 和 tick() 串行化，吞吐归零。正确做法是每个 bucket 自带一把 std::shared_mutex（读多写少场景下比 std::mutex 更轻量）：
-
add_task()只需获取对应 bucket 的独占锁（write lock），push 后立即释放 -
tick()扫描当前 bucket 时，先尝试共享锁（read lock），若发现堆非空再升级为独占锁 pop —— 实际中可简化为直接上独占锁，因 tick 是周期性单线程调用 - 切忌用
std::mutex锁住整个轮数组，那等于把并发调度退化成单线程排队
示例关键片段：
struct TaskCompare {
bool operator()(const Task* a, const Task* b) const {
if (a->priority != b->priority) return a->priority > b->priority;
return a->id > b->id; // 防同优先级饿死
}
};
注意 time_point 类型和系统时钟漂移带来的精度陷阱
用 std::chrono::steady_clock 而非 system_clock 计算 expire_time_ms，否则 NTP 校时会导致任务提前或跳过。但 steady_clock 的 time_since_epoch() 值极大（纳秒级），直接转毫秒再模槽数量易溢出或截断误差。
立即学习“C++免费学习笔记（深入）”；
- 推荐做法：记录首次启动时的
steady_clock::now()作为 base，后续所有expire_time_ms都基于该 base 做相对偏移（duration_cast<milliseconds>(now - base).count()） - 每层时间轮的槽数必须是 2 的幂（如 64、256），方便用位运算替代取模，避免负数取模 bug
- 当任务设置的延迟超过最高层覆盖范围（例如设了 30 天后执行），不要静默丢弃，应抛出
std::out_of_range或降级为用std::thread+sleep_until单独处理
真正难的不是堆和轮怎么嵌套，而是让每个槽的堆在高吞吐下不争抢、不假死、不漏触发——锁粒度、时钟源、溢出检查，三者缺一就会在线上突然掉任务。
