std::chrono+std::map不适合高并发心跳检测，因其插入/删除为O(log n)且需全局锁，超时扫描为O(n)线性遍历；应改用分层时间轮实现O(1)插入与摊还O(1)超时处理。
为什么 std::chrono + 普通 std::map 不适合高并发心跳检测
直接用 std::map<time_point, callback> 存心跳超时时间，看似简单，但每秒万级连接时会迅速暴露问题：每次插入/删除都要 O(log n) 平衡树重平衡，且所有线程竞争同一把红黑树锁（即使只读操作在 libstdc++ 中也可能触发迭代器校验）。更关键的是，超时扫描必须遍历整个 map 找出已到期项——这在连接数增长时变成 O(n) 线性扫描，CPU 负载陡增。
实操建议：
- 避免在高频写入场景下使用
std::map或std::set存储定时任务 - 不要在单个容器中混合不同精度的定时需求（比如既有 10ms 心跳，又有 5s 清理任务）
- 心跳检测必须满足“插入快、删除快、超时扫描开销与当前活跃连接数无关”三个硬条件
用分层时间轮实现 O(1) 插入和摊还 O(1) 超时处理
核心是两级时间轮：第一级为「秒级轮」（60 槽），第二级为「毫秒级轮」（1000 槽），两者通过余数映射绑定。每个连接的心跳超时时间被拆解为「基础秒数 + 偏移毫秒数」，分别落入对应槽位。这样插入只需计算两个取模，删除只需定位到具体槽位链表头尾，超时扫描则固定每毫秒推进一次指针，只检查当前毫秒槽内节点。
关键细节：
立即学习“C++免费学习笔记（深入）”；
- 所有槽位用
std::vector<std::list<TimerNode*>>实现，避免指针跳跃访问；std::list保证删除不使其他迭代器失效 - 每个
TimerNode存expiration_ms（绝对时间戳，单位毫秒），而非相对延迟，规避重置误差累积 - 优先级通过 slot 索引隐式体现：毫秒轮内节点天然比秒轮内节点更紧急；同槽内按插入顺序 FIFO 处理，如需显式优先级，可在
TimerNode中加priority字段并改用std::priority_queue替换std::list（但会牺牲 O(1) 删除）
std::atomic<uint64_t> 推进指针为何不能替代 std::chrono::steady_clock
有人尝试用原子计数器模拟时间轮指针，认为比调用系统时钟快。但实际运行中会出现严重漂移：原子递增频率受 CPU 调度、中断、缓存一致性协议影响，无法与真实流逝时间对齐。当网络抖动导致某次 tick 延迟 2ms，原子计数器仍按“假设每毫秒+1”推进，后续所有超时判断全错位。
正确做法是每次 tick 都调用 std::chrono::steady_clock::now() 获取真实时间，再映射到时间轮坐标：
auto now = std::chrono::steady_clock::now();
uint64_t now_ms = std::chrono::duration_cast<std::chrono::milliseconds>(
now.time_since_epoch()).count();
size_t ms_slot = (now_ms % 1000);
size_t sec_slot = ((now_ms / 1000) % 60);
注意：now_ms 必须用 count() 得到整数，不可用 time_since_epoch().count() / 1000 截断毫秒——否则丢失精度，导致跨秒时漏触发。
如何避免多线程下 TimerNode 被重复释放或提前释放
典型错误是让 worker 线程直接 delete TimerNode，而 I/O 线程还在往该节点写数据（比如收到新心跳包后更新 last_active_time）。必须分离生命周期管理：所有 TimerNode* 由专属内存池（如 boost::object_pool<TimerNode> 或自定义 slab 分配器）分配，且只允许一个线程（通常是 timer thread）执行回收逻辑。
实操要点：
- 插入定时器时，从池中
construct()新节点，并用std::shared_ptr<TimerNode>包裹回调上下文，确保业务逻辑持有引用时不被误删 - 超时触发时，timer thread 将节点从时间轮链表摘下，放入本地待处理队列，再批量调用回调函数；回调返回后才调用
pool.destroy(node) - 禁止在回调函数中调用
cancel()或任何可能再次修改时间轮结构的操作——应改为发消息给 timer thread 异步处理
最易被忽略的是：时间轮槽位数组本身必须用 std::vector 预分配固定大小，且禁止在运行时 resize。否则迭代器失效会导致遍历崩溃，而这种崩溃往往只在压测后期偶发，极难复现。
