HashedWheelTimer默认配置会导致心跳检测失效，因其tickDuration=100ms、ticksPerWheel=512，造成超时偏差大、槽位冲突严重（百万任务挤在512槽）、指针处理阻塞，需按心跳精度调优参数。
HashedWheelTimer 能扛住百万级心跳检测，但直接 new 一个默认实例就会在 10 万连接后开始丢任务、延迟飙升——关键不在“用不用”，而在“怎么配”。
为什么默认 HashedWheelTimer 在心跳场景下会崩
Netty 的 HashedWheelTimer 默认构造参数是：tickDuration=100ms、ticksPerWheel=512，意味着它一圈最多覆盖 51.2 秒，且每 100ms 才检查一次槽位。心跳检测通常要求 3–30 秒超时，且需毫秒级响应精度：
- 超时判断不准：100ms 粒度下，实际延迟可能偏差 ±100ms，对 5 秒心跳已超 2% 误差
- 槽位冲突爆炸：512 个槽放百万任务，平均每个槽要链式挂载近 2000 个任务，遍历链表触发耗时从 O(1) 退化为 O(N)
- 指针推进阻塞：单次 tick 处理耗时超过
tickDuration，导致后续 tick 堆积，整个时间轮“卡顿”
心跳检测专用的参数配置策略
目标是让每个连接的心跳超时任务落在独立槽位、触发零竞争、不跨槽遍历。核心是让 tickDuration ≤ 心跳检测最小容忍延迟（如 100ms），同时控制槽位负载
-
tickDuration = 10（单位TimeUnit.MILLISECONDS）：保证 10ms 级精度，适配 3s/5s/10s 等常见心跳周期 -
ticksPerWheel = 4096：总覆盖时长 40.96 秒，足够覆盖绝大多数心跳超时窗口（如 30s timeout + 10s grace） - 线程数显式设为 1：
new HashedWheelTimer(new DefaultThreadFactory("heartbeat-timer"), 10, TimeUnit.MILLISECONDS, 4096)，避免多线程争抢指针和桶锁 - 禁用泄漏检测：
new HashedWheelTimer(..., true)第五个参数传false，减少高频添加/取消时的 WeakReference 开销
心跳任务的添加与取消必须成对、无残留
每个连接绑定一个 Timeout，但连接断开时若未 cancel，该任务会一直占槽直到超时，内存和 CPU 双泄露：
- 添加任务时务必保存
Timeout引用：Timeout timeout = timer.newTimeout(task, heartbeatTimeout, TimeUnit.SECONDS) - 连接关闭前必须调用
timeout.cancel()；Netty 中建议在channelInactive()或exceptionCaught()里统一 cancel - 不要依赖
Timeout.isExpired()判断是否已触发——它只反映“是否被轮到过”，不等于“是否执行完”，cancel 才是唯一安全释放方式 - 避免在
TimerTask.run()内部再调用newTimeout()（比如续期），应改用timeout.reschedule(...)，否则旧任务残留+新任务重复注册
当连接数突破 50 万后，单时间轮仍可能成为瓶颈
即使参数调优，单个 HashedWheelTimer 实例的指针推进、槽位遍历、链表清理仍是单线程串行操作。实测在 80 万连接、3 秒心跳、10ms tick 下，单轮 tick 耗时可达 8–12ms，接近 tick 间隔本身：
- 方案一：按连接 ID 分片，启动多个
HashedWheelTimer实例（如 4 个），每个负责 1/4 连接，通过connId % 4路由 - 方案二：升级到分层时间轮（如 Kafka 的多级 TimingWheel），但 Netty 原生不支持，需自行封装或换用
io.netty.util.HashedWheelTimer的 fork 版本 - 最简兜底：把心跳检测逻辑从时间轮中剥离，改用
EpollEventLoop自带的scheduledTaskQueue（基于堆），虽然插入 O(log n)，但百万连接下实测总延迟更稳——因为它是和 IO 事件共用同一线程，无上下文切换开销
真正棘手的不是“怎么加定时器”，而是连接生命周期管理没跟上时间轮节奏：一个没 cancel 的 timeout，会在内存里躺平几十秒，拖慢整圈轮转。这比算法选型更常引发线上抖动。
