std::chrono+简单时间轮不适用于高并发心跳检测，因其高频now()调用引发严重cache miss和系统调用开销，且缺乏优先级插入与批量过期回调能力，导致超时延迟抖动大（P99≥80ms）；需改用双缓冲槽指针、原子游标、每槽三分级队列及无锁回调投递等优化手段。
为什么 std::chrono + 简单时间轮不适用于高并发心跳检测
因为默认的 std::chrono::steady_clock 高频调用（如每 10ms 检查一次）在万级连接下会触发大量 cache miss 和时钟系统调用，实际测得单核 CPU 占用可飙到 40% 以上；更关键的是，标准库没有提供「按优先级插入」和「批量过期回调」能力，导致心跳超时判断延迟抖动大（实测 P99 达 80ms+）。必须绕过频繁 now() 调用，并把优先级逻辑下沉到槽位结构里。
TimeWheel 的槽位设计必须支持 O(1) 优先级分组
不能每个槽存一个 std::list，那样插入/删除仍是 O(n)；正确做法是每个槽维护 3 个固定优先级队列（high/mid/low），用 std::vector 预分配内存，插入时直接 push_back。关键点在于：优先级不是全局排序，而是「同槽内分组」——超时检查时先扫 high 组，空了再扫 mid，避免低优任务阻塞高优回调。
- 槽大小建议设为 256，层级数 2（毫秒级 + 秒级），覆盖 65 秒范围足够心跳场景
- 每个槽的
high组最多存 32 个节点，超限时自动降级到mid，防止单槽阻塞 - 节点结构体必须紧凑：
struct TimerNode { uint64_t expire_ms; void* data; uint8_t priority; };，避免指针跳转
心跳检测如何避免锁竞争和 ABA 问题
不用 std::mutex 保护整个时间轮，而用「双缓冲槽指针 + 原子游标」：主循环只读当前槽（current_slot 是 std::atomic），心跳更新时写入下一个槽（next_slot），每 10ms 用 fetch_add 推进游标并原子交换两个槽指针。这样读写完全分离，CAS 失败率低于 0.02%。
- 心跳续期操作只需修改节点
expire_ms字段，无需移动节点位置 - 节点
data指向连接上下文，但必须确保该内存生命周期长于定时器——推荐用std::shared_ptr管理，且只在超时回调里释放 - 绝对不要在回调里调用
delete this或close(fd)，统一交由 IO 线程处理，否则可能触发 use-after-free
TimerNode 回调执行必须解耦到业务线程池
时间轮线程只负责「发现超时节点」，不能直接执行业务逻辑（比如发断连包、清理 session）。否则高优心跳回调卡住会导致后续所有定时器堆积。正确做法是：超时节点打包成 std::vector，通过无锁环形队列（moodycamel::ConcurrentQueue）投递给业务线程池。
- 回调函数签名强制为
void(*cb)(void*, int)，第二个参数传入优先级，业务侧可据此调整处理策略 - 环形队列需预设容量（建议 8192），满时丢弃
low优先级节点，保障高优不丢 - 实测显示：10 万连接下，从超时检测到业务线程收到通知的延迟稳定在 0.3~0.7ms（P99）
真正难的不是实现多层时间轮，而是让每个槽的优先级分组不互相污染、让心跳续期不触发重哈希、让超时回调不反压定时器主线程——这些细节在压测时才会暴露，但线上一旦出问题就是连接雪崩。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
