HashedWheelTimer比ScheduledExecutorService更适合心跳检测，因其O(1)调度、单线程驱动、内存稳定且精度可调，符合心跳高频、低耗、容忍误差的特点，并经Netty生产验证。
HashedWheelTimer 为什么比 ScheduledExecutorService 更适合心跳检测
因为心跳检测是高频、低耗、大批量的延迟任务，而 ScheduledExecutorService 每个任务都走优先队列插入/弹出，时间复杂度是 O(log n)，百万级任务下调度开销会陡增；HashedWheelTimer 把任务按到期时间哈希到固定槽位，添加和触发都是 O(1)，且只用单线程驱动轮子转动，内存与 CPU 占用稳定。
典型反例：用 ScheduledExecutorService 为每个长连接维护一个 30s 心跳超时任务，100 万连接 ≈ 100 万个 Runnable + 堆节点，GC 压力大、调度延迟抖动明显；HashedWheelTimer 只需一个线程 + 固定大小数组（如 512 槽），所有任务共用同一轮子。
- 心跳任务本身执行极快（通常只是判断 channel 是否活跃、发一个 ping 包），符合
HashedWheelTimer“短平快”前提 - 心跳允许一定误差（比如 ±200ms），不需要毫秒级精准，而
HashedWheelTimer的精度由tickDuration决定，可主动放宽 - Netty 自身的
IdleStateHandler底层就是靠它驱动，说明已通过生产级验证
初始化 HashedWheelTimer 的关键参数怎么设
错误配置会导致任务延迟不准、轮子卡死或内存暴涨。核心是三个参数的协同：槽数量（ticksPerWheel）、每格时长（tickDuration）、线程工厂（ThreadFactory）。
-
tickDuration = 100ms 是常见起点：太小（如 1ms）导致轮子转得太勤，CPU 空转；太大（如 1s）会让 30s 心跳的误差达到 ±1s，可能误判断连 -
ticksPerWheel = 512覆盖约 51.2s，够覆盖常见心跳周期（如 dubbo 默认 60s 心跳，3 次未响应即断连 → 180s 超时，此时需调高至 2048 或启用多级轮） - 必须传自定义
ThreadFactory并设名称（如"heartbeat-wheel"），否则默认线程名不可读，线上排查时无法区分是哪个轮子在跑 - 避免复用全局单例：不同业务（如心跳 vs 订单超时）应分用独立
HashedWheelTimer实例，防止互相干扰
如何安全地注册/取消心跳检测任务
注册和取消必须成对，否则任务泄漏，HashedWheelTimer 不会自动清理已取消但未触发的任务——它只在 tick 触发时检查 Timeout.isCancelled()。
- 注册用
newTimeout()，返回Timeout对象，**必须保存引用**（比如存在Channel.attr()里），不能丢弃 - 取消必须显式调用
timeout.cancel()，且推荐在channelInactive()和exceptionCaught()中都做一遍，覆盖异常断连场景 - 不要在
run()回调里直接再调newTimeout()注册下一次心跳——这会阻塞轮子线程；应先退出回调，再异步提交（如用eventLoop().execute()） - 任务体里禁止阻塞操作（如同步 DB 查询、HTTP 调用），否则整个轮子卡住，所有后续心跳都会延迟
为什么心跳任务不能共享同一个 Timeout 实例
每个连接的心跳超时是独立状态，复用 Timeout 实例会导致 cancel 逻辑错乱：A 连接断开调了 cancel()，B 连接还在用同一个实例，就再也收不到超时通知了。
正确做法是每次心跳重置都新建 Timeout：
Timeout newTimeout = timer.newTimeout(timeoutTask, 30, TimeUnit.SECONDS); channel.attr(HEARTBEAT_TIMEOUT).set(newTimeout); // 存到 channel 上
注意：timeoutTask 可以是同一个对象（它不保存状态），但 newTimeout 必须每次新建。这也是为什么 Netty 的 IdleStateHandler 内部为每个 channel 维护独立的 timeout 引用。
最容易被忽略的是：轮子线程不参与 I/O，它只负责“喊一嗓子该超时了”，真正的断连动作（如 channel.close()）必须交还给对应 channel 的 EventLoop 执行，否则会触发线程安全异常。
