海量长连接超时剔除采用分层动态时间轮：按协议与活跃度分三级轮（秒/分钟/溢出链表），onconnect时分级插入；tick时自动迁移任务至合适层级；心跳仅更新expire_time并条件迁移；超时执行分离为标记与异步清理。
直接用分支结构配合动态时间轮做海量长连接超时剔除，核心不是“加if else”，而是把连接状态、超时策略、轮次跳转这三类逻辑拆开处理，让每条路径清晰可测、无冗余判断。
按连接活跃度分层管理超时逻辑
不要给所有连接统一设 30 秒超时。真实业务中，不同连接的预期行为差异很大：
- Websocket 心跳连接：通常 30–60 秒无数据即判定异常，适合放进秒级时间轮（如第一级轮，槽位 64，精度 1s）
- MQTT 持久会话连接：可能数分钟无消息但合法，应归入分钟级轮（如第三级轮，覆盖 0–63 分钟）
- 临时调试连接或管理通道：允许更长空闲（如 10 分钟），走溢出链表+降级检查机制，不挤占主轮资源
分支点就落在连接建立时的 onConnect 回调里：根据协议类型、客户端标识、业务标签等字段，决定初始插入哪一层时间轮，并打上 level 标记（0/1/2）和优先级权重。
用多级轮溢出驱动自动降级与升频
动态时间轮的“动态”不在运行时改槽数，而在任务到期前自动迁移层级。关键分支在 tick 触发时的槽位扫描环节：
- 当前轮（如秒轮）某槽位触发，遍历其中所有 TimerNode
- 对每个节点计算剩余时间 remain_ms = expire_time – now
- 若 remain_ms
- 若 remain_ms
- 若 64ms ≤ remain_ms
- 若 remain_ms ≥ 64×64s → 推入溢出链表，由后台低频线程兜底扫描
这个分支逻辑把“长期任务塞进短轮导致链表退化”的风险彻底规避，也避免了单层轮面对混合周期任务时的性能塌方。
心跳刷新走无锁路径，绕过主轮重插开销
每秒数万连接收心跳包再重置超时，如果每次都删旧节点+插新节点，即使 O(1) 也会因内存分配和链表指针操作引发缓存抖动。实战中应走轻量分支：
- 收到心跳后，仅更新该连接绑定的 TimerNode 中的 expire_time 字段
- 检查该节点当前所在轮级是否仍适配新 expire_time：若仍在同级轮内，无需移动；否则触发一次跨轮迁移（只改指针，不 new/delete）
- 迁移动作由独立的 migration_queue 批量提交，调度器线程在每次 tick 后统一处理，避免网络线程阻塞
这种设计下，95% 的心跳刷新变成纯内存字段写入，真正需要轮次调整的不足 5%，大幅降低锁竞争和 CPU cache miss。
超时执行阶段分离回调与清理，防阻塞扩散
连接超时后不能直接在定时器线程里 close(fd) + delete conn —— 一旦回调函数含日志、DB 写入或远程调用，就会拖慢整个 tick 周期，导致后续连接检测延迟。
- 超时扫描阶段只做两件事：将待关闭连接 ID 推入一个 lock-free spsc 队列；标记 conn->state = TIMEOUT_PENDING
- 另起专用清理线程，持续消费该队列，执行 fd 关闭、内存释放、统计上报等耗时操作
- 网络 IO 线程在下次 epoll_wait 前检查 conn->state，跳过已标记连接，避免无效事件分发
这种执行路径分离，让时间轮的 tick 节奏严格可控，抖动低于 100μs，支撑每秒 50w+ 连接的精准驱逐。
