std::chrono + std::thread 不适合高并发定时任务，因其依赖频繁线程唤醒、锁竞争和独立调度，导致CPU与内核开销爆炸；时间轮通过环形数组+槽位映射实现O(1)插入与推进，配合无锁链表、对象池、cache line对齐及CLOCK_MONOTONIC计时，可高效支撑10万+任务。
为什么 std::chrono + std::thread 不适合高并发定时任务
因为 std::this_thread::sleep_until 在大量任务下会频繁唤醒线程、争抢锁，且每个任务都需独立线程或条件变量协调，CPU 和调度开销爆炸。真实场景中，10 万+ 定时任务用 std::thread 模拟，往往还没跑起来就卡死在 pthread_cond_wait 或被内核 OOM kill。
时间轮（Timing Wheel）本质是空间换时间：把「何时触发」映射为数组下标，O(1) 插入、O(1) 推进、O(k) 执行到期任务（k 是该槽位任务数）。C++ 实现关键不在轮子本身，而在如何避开内存分配、避免伪共享、绕过锁竞争。
- 禁用
std::shared_ptr或std::make_shared存储任务 —— 高频 new/delete 触发 malloc 争抢，改用对象池（boost::object_pool或自建std::vector<:aligned_storage_t>）预分配 - 每个槽位（bucket）用无锁单链表（
std::atomic+ next 指针 CAS）代替std::list，否则push_back锁住整个链表 - 时间轮推进必须单线程驱动（如 dedicated timer thread），多线程同时调用
tick()会导致槽位跳变、任务漏执行
如何实现带优先级的槽位分层结构
普通时间轮只支持「最早触发时间」，但业务常需要「紧急任务插队」——比如心跳超时要立刻处理，而日志刷盘可延迟 500ms。不能靠插入时遍历重排（O(n)），也不能每个优先级建一个轮子（内存翻倍）。
正确做法是分层：底层用 256 槽 * 200ms 精度的基础轮（覆盖 51.2s），上层设 8 个「紧急槽」，每个对应 1~8 级优先级，独立链表，不参与 tick 推进，由 submit_with_priority() 直接触发。
- 低优先级任务走基础轮：
insert_into_wheel(task, delay_ms)→ 计算槽位索引 + 余数轮数，写入对应 bucket - 高优先级任务（priority > 3）绕过轮子，直接
push_front到对应紧急链表，由 timer thread 每次 tick 后立即遍历这 8 个链表 - 注意紧急链表节点必须用
std::atomic标记是否已执行，防止多线程 submit 时重复入链
Linux 下 clock_gettime(CLOCK_MONOTONIC) 为何比 gettid() + rdtsc 更稳
很多方案用 rdtsc 测微秒级时间，但现代 CPU 动态调频、多核 TSC 不同步，rdtsc 在容器或云环境误差可达 ±20%；gettid() 只是线程 ID，和时间无关——这是常见误读。
clock_gettime(CLOCK_MONOTONIC) 由内核维护，不受系统时间调整影响，且 Linux 5.0+ 默认启用 vvar 页优化，调用开销压到 20ns 以内，实测比 std::chrono::steady_clock::now() 快 3×（后者内部仍可能 fallback 到 syscall）。
- 务必用
CLOCK_MONOTONIC，不是CLOCK_REALTIME—— 后者会被 NTP 调整，导致定时任务提前/延后触发 - 初始化时调用一次
clock_gettime获取 base time，后续所有 tick 计算用相对差值，避免反复 syscall - 若需纳秒级精度，直接读取
ts.tv_sec * 1000000000ULL + ts.tv_nsec，别用std::chrono::nanoseconds构造 —— 隐式转换有函数调用开销
避免 false sharing 的 cache line 对齐实战
时间轮的 bucket 数组若未对齐，多个相邻槽位可能落在同一 cache line（通常 64 字节），当不同 CPU 核心更新不同 bucket 时，会因缓存一致性协议（MESI）互相无效化，性能暴跌 30%+。
解决方案不是简单加 alignas(64)，而是每个 bucket 单独对齐，并填充冗余字段隔离：
struct alignas(64) Bucket {
std::atomic<uint64_t> task_head{0};
char _pad[56]; // 保证下一个 Bucket 从新 cache line 开始
};
</uint64_t>
- 用
static_assert(sizeof(Bucket) == 64, "cache line misalignment")强制校验 - 禁止在 Bucket 内放
std::mutex或std::vector—— 它们会破坏对齐且引入锁 - 如果使用 NUMA 架构，bucket 数组应
numa_alloc_onnode分配在 timer thread 绑定的 CPU 节点上
真正难的从来不是轮子怎么转，而是当 10 万个任务在 32 核机器上每秒触发 50 万次时，cache line 一抖，延迟毛刺就从 50μs 跳到 8ms —— 这种问题不会报错，只会让你在凌晨三点对着 p99 延迟曲线发呆。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
