怎么利用 HashedWheelTimer 处理具有数万路并发 TCP 连接的超时重传与断线自动重连逻辑

说实话，对于处理数万路并发TCP连接的超时重传和断线重连，HashedWheelTimer确实是一个非常经典的解决方案。不过，用对用错，效果天差地别——关键在于搞清楚它的设计边界和那些容易踩的坑。

先说一下它的定位：这不是一个面面俱到的万能定时器。它的真正角色，是专为「大量中长周期、低精度要求」的延迟任务而设计。什么场景？就是3秒、5秒、10秒级别的超时重传，以及30秒到2分钟级别的断线检测。这些任务落在它的舒适区里，表现会非常出色。但反过来，如果你需要毫秒级的精度，或者要频繁地取消和重新调度任务，那它反而会因为哈希槽的竞争和取消操作的开销拖慢整体性能。这一点，需要格外警惕。

HashedWheelTimer 适合高并发连接的超时调度吗？

答案是肯定的，但得把话说明白。它的调度能力由两个核心参数决定：tickDuration（每次tick的间隔）和ticksPerWheel（轮子上的槽位数）。这两者的乘积，决定了它能表达的最大延迟。同时，轮子的大小直接影响内存占用和哈希冲突的概率。

对于数万路连接这个量级，行业内的经验配置通常是这样的：tickDuration = 100（毫秒），ticksPerWheel = 512，这样算下来可以覆盖大约51.2秒的延迟。之后，再根据实际最长超时需求往上调整即可。一句话总结：参数选对了，性能就稳了。

如何为每条 TCP 连接绑定独立的超时任务而不泄漏内存？

问题来了。每次重传或重连，都去new一个Timeout对象，但在连接关闭时却忘了显式调用timeout.cancel()。结果就是，HashedWheelTimer内部的队列不停堆积，最终导致OOM。这是一个非常经典且致命的陷阱。

Netty社区推荐的做法是把Timeout的引用存到ChannelHandlerContext的attr()中，然后在channelInactive()或exceptionCaught()里统一进行清理。来看这段典型的代码：

private static final AttributeKey RECONNECT_TIMEOUT = AttributeKey.valueOf("reconnectTimeout");

// 启动重连定时任务
ctx.channel().attr(RECONNECT_TIMEOUT).set(timer.newTimeout(
    timeout -> doReconnect(ctx), 30, TimeUnit.SECONDS));

// 在 channelInactive 中清理
@Override
public void channelInactive(ChannelHandlerContext ctx) throws Exception {
    Timeout t = ctx.channel().attr(RECONNECT_TIMEOUT).getAndSet(null);
    if (t != null && !t.isCancelled()) {
        t.cancel(); // 必须调用，否则任务仍在轮子里等待触发
    }
    super.channelInactive(ctx);
}

这里有个小细节要注意：t.cancel()是线程安全的，可以在任意线程调用。不过，别重复对一个已经cancel掉的对象再调用cancel——虽然不报错，但确实浪费CPU。

为什么重传定时任务总在连接已关闭后还执行？

这不是HashedWheelTimer的bug，而是业务逻辑里缺少一道“状态兜底”。很多开发者只依赖定时器去触发动作，却没在Timeout的task执行前，先检查一下连接是否还活着。

正确的做法应该包含以下几层防护：发送重传前，必须先检查if (!ctx.channel().isActive()) return;；重连逻辑里，要先确认if (ctx.channel().isRegistered() && !ctx.channel().isActive())，再真正发起connect；最后，要避免在channelInactive()之后还调用ctx.writeAndFlush()——此时channel已经不安全地关闭了，会抛出RejectedExecutionException，或者更糟，静默丢包。

一个更稳妥的方案是：在Timeout任务里直接读取Channel的实时状态，而不是依赖一个外部flag变量（flag容易被多线程误更新，风险很高）。

和 EventLoop 自带的 schedule 方法比，该不该换用 HashedWheelTimer？

这取决于你的超时任务密度。如果每秒要新增数百个30秒的超时任务，用EventLoop.schedule()会导致底层堆排序定时任务队列（SortedSet）频繁地rehash和比较，CPU消耗会直线上升。而HashedWheelTimer是O(1)的插入复杂度，加上固定的tick触发机制，吞吐量非常稳定。

但代价是精度上的妥协。你不能指望它精确到±1毫秒——实际误差范围是[0, tickDuration)。比如tickDuration=100的情况下，一个设定为3000ms的重传任务，实际触发时间可能在3000到3099毫秒之间。对于TCP超时重传来说，这个精度完全可以接受。但如果你是在做RTT采样或拥塞控制窗口调整这类对时间精度敏感的工作，那还是得换回schedule()或选用更高精度的方案。

另外还要注意一点：HashedWheelTimer通常是全局共享的资源。如果有多个业务模块一起使用它，一定要确保没有任务被长期阻塞——比如在Timeout的任务里做了同步IO操作。否则，整个wheel的tick线程都会被卡住，后果不堪设想。