应选多层时间轮；因其通过分频管理实现O(1)操作，单层在千万级心跳场景下因空槽遍历开销爆炸而不可用，3–4层结构兼顾覆盖范围与实现复杂度。
时间轮选单层还是多层？关键看连接活跃度分布
单层时间轮在千万级心跳场景下基本不可用——它要求槽位数 ≥ 最大超时时间（比如 300 秒），若以毫秒为精度，就要 30 万+ 槽；而活跃连接散落在不同到期时刻，遍历空槽开销爆炸。多层级时间轮（Hierarchical Timing Wheel）本质是“分频管理”：高频小粒度管近期（如 0–64ms），低频大粒度管远期（如 65ms–10s、10s–5min），让插入/推进/过期操作稳定在 O(1) 或摊还 O(1)。
实际部署中，3–4 层最常用：第一层 256 槽 × 10ms（覆盖 2.56s），第二层 64 槽 × 256×10ms ≈ 163s，第三层 64 槽 × 163s ≈ 2.7h，第四层兜底长连接（如 24h）。层数再多收益锐减，反而增加跨层迁移逻辑复杂度。
如何把连接指针挂到对应槽位？别直接存 std::shared_ptr
每个连接对象（如 Connection）需携带两个关键字段：expiration_time（绝对时间戳，单位 ms）和 current_wheel_level（当前所在层级）。插入时不是简单取模，而是逐层判断归属：
- 计算距当前时间的剩余毫秒数
delta = expiration_time - now_ms - 若
delta → 挂入 level0 对应槽 - 否则除以该层总跨度，落入上一层槽位，并更新
current_wheel_level
重点：槽内链表节点必须是轻量结构体（如仅含 next 指针 + connection_id），避免存储 std::shared_ptr<connection></connection> —— 它会触发原子计数器增减，在高并发插入/过期时成为性能瓶颈。真实连接对象由外部池（如 ObjectPool<connection></connection>）统一管理，时间轮只负责调度生命周期。
立即学习“C++免费学习笔记（深入）”；
tick() 推进时为何要处理跨层迁移？不迁就漏掉超时
每 tick（如 10ms）只推进最低层。当 level0 某个槽被清空时，里面所有连接若未真正超时（即 expiration_time > now_ms），就必须重新计算其 delta，降级到更高层对应槽位。漏掉这步，连接会永远滞留在已清空的旧槽，导致假在线。
常见错误写法：if (delta —— 这里 <code>rehash_to_upper_level() 必须同步更新节点的 current_wheel_level 和指针位置，且不能持有锁跨层操作（易死锁）。推荐方案：level0 tick 时批量收集需迁移的节点，释放 level0 锁后，在无锁队列中异步重入时间轮高层插入逻辑。
千万连接下 std::vector 槽数组会爆内存？换 std::unique_ptr<:vector>></:vector>
假设 4 层，每层 256 槽，指针大小 8 字节，粗算内存 = 4 × 256 × 8 ≈ 8KB，完全不是问题。真正吃内存的是槽内链表节点本身 —— 千万连接意味着千万个节点。但更隐蔽的问题是：如果用 std::vector<:list>></:list>，vector 的连续内存分配在百万级槽位时可能失败（尤其 Windows 下 VirtualAlloc 碎片化）。
实操建议：std::vector 只用于存各层槽首指针（即 std::vector<slotnode></slotnode>），每个槽的链表头用堆分配（new SlotNode），或更优：用 std::unique_ptr<:vector>></:vector> 管理槽数组本身，避免栈溢出，也方便按需 resize 高层（比如发现第三层长期只有前 10 个槽非空，可后续裁剪）。
另外，clock_gettime(CLOCK_MONOTONIC, &ts) 比 std::chrono::steady_clock::now() 在 Linux 上少一次 syscall 封装，微秒级心跳下值得抠这点开销。
