std::chrono+简单循环心跳检测会掉帧漏超时，因sleep精度低且O(N)轮询效率差；应改用两级时间轮，满足固定tick、常数访问、毫秒精度与百万连接支持。
为什么 std::chrono + 简单循环做心跳检测会掉帧甚至漏超时
因为标准库的 std::this_thread::sleep_for 不保证唤醒精度，尤其在高负载或低优先级线程下，实际休眠时间可能比预期长几十毫秒；更严重的是，轮询检查所有任务的时间复杂度是 O(N)，当心跳连接数上万时，单次扫描就可能拖慢整个调度周期。
真正稳定的心跳检测必须满足两个硬性条件：固定 tick 步进（如每 10ms 触发一次 tick）、每个任务只被访问常数次。时间轮（Timing Wheel）天然适配这点——它把未来一段时间切分为固定槽位，任务按剩余 ttl 散列到对应槽，tick 时只处理当前槽。
- 别用
std::set<std::pair<time_t, TaskId>>模拟优先级队列：插入/删除都是 O(log N)，且无法按时间分片批量清理 - 避免在 tick 回调里做阻塞操作（如日志写磁盘、网络 send）：这会卡住整个时间轮推进，导致后续所有槽延迟
- Linux 下注意
CLOCK_MONOTONIC而非CLOCK_REALTIME：后者受系统时间调整影响，会导致时间轮倒退或跳跃
如何用两级时间轮实现毫秒级精度 + 百万级连接支持
单层时间轮在支持大范围超时（如 30 分钟）和高精度（如 10ms tick）时，内存开销爆炸（30×60×100 = 18 万个槽）。两级结构是工业级方案：第一级（wheel_0）管 0–511 × tick（比如 0–5.11s），第二级（wheel_1）管更高位，通过溢出迁移维持 O(1) 插入和 O(1) tick 处理。
关键不是“轮子怎么转”，而是“任务怎么放、什么时候迁、迁到哪”。下面这段核心逻辑决定了是否真能扛住压测：
立即学习“C++免费学习笔记（深入）”；
void add_task(TaskId id, int ttl_ms) {
int ticks = ttl_ms / TICK_MS;
if (ticks < WHEEL_0_SIZE) {
wheel_0[(cur_tick + ticks) % WHEEL_0_SIZE].push_back(id);
} else {
// 计算在 wheel_1 的槽位：高位部分，向下取整到 wheel_1 粒度
int level1_ticks = (ticks - WHEEL_0_SIZE) / WHEEL_1_GRANULARITY;
wheel_1[(cur_level1_tick + level1_ticks) % WHEEL_1_SIZE].push_back(id);
}
}
-
WHEEL_0_SIZE建议设为 256 或 512（2 的幂，方便取模优化） -
WHEEL_1_GRANULARITY必须等于WHEEL_0_SIZE，否则迁移逻辑错位 - 每次 tick 后，若
cur_tick % WHEEL_0_SIZE == 0，则需推进cur_level1_tick并检查 wheel_1 当前槽是否要迁回 wheel_0
优先级怎么嵌进时间轮里而不破坏 O(1) 特性
时间轮本身不排序，优先级不能靠“在槽里再堆一个堆”。正确做法是：每个槽内部用多个优先级队列（如 3 层：high/normal/low），但只在 tick 触发时按序消费——即每个槽是一个 std::array<std::vector<TaskId>, 3>，而不是 std::priority_queue。
这样既保持插入 O(1)，又确保高优任务总在同 tick 内先执行。心跳检测类任务一律走 high 队列，业务定时任务走 normal，统计上报类走 low。
- 别对每个任务存完整
std::function：用 ID 查表回调，避免内存碎片和拷贝开销 - 禁止在
high队列里放耗时 > 1ms 的操作：否则会挤占其他高优任务的执行窗口 - 优先级迁移规则要显式定义：比如连续 3 次心跳超时，自动升为
high直到恢复，这个逻辑不在时间轮内，而在任务状态机中
实测调优时最容易被忽略的三个底层细节
很多团队实现完功能就上线，结果在 20% CPU 负载下延迟毛刺翻倍——问题往往不出在算法，而在与 OS 和硬件的交互细节上。
- 线程绑定：
pthread_setaffinity_np把时间轮线程绑到独占 CPU 核，关闭该核的intel_idle和cpufreq，否则 tick 周期抖动可达 ±200μs - 内存预分配：每个 wheel_0 槽的
std::vector调用reserve(64)，避免高频 push_back 触发多次 realloc - cache line 对齐：把
cur_tick和cur_level1_tick放在独立 cache line（用alignas(64)），防止伪共享导致多核更新时性能暴跌
时间轮不是越深越好，两级已覆盖 99.9% 场景；真正的瓶颈永远在你没 profile 过的那行日志打印、那个没关的调试 assert、或者那个以为“只是读”的全局变量访问。
