应全局共享单例 HashedWheelTimer 并合理调参，避免每连接新建实例导致线程爆炸与内存激增；心跳任务需绑定 Channel 生命周期动态注册/取消，优先选用 IdleStateHandler 实现空闲检测。
直接结论：别用每个连接配一个 HashedWheelTimer，全局共享单例 + 合理调参，才能扛住 10 万+ 连接的心跳调度。
为什么不能每个连接 new 一个 HashedWheelTimer
每次 new HashedWheelTimer 都会启动一个独立线程（workerThread），10 万个连接就 10 万个线程 —— 不是 OOM 就是线程调度雪崩。Netty 官方文档明确警告：“Do not create many instances”。更隐蔽的问题是，每个实例默认 512 槽位、100ms tick，内存和 CPU 调度开销呈线性放大，实际心跳延迟反而不可控。
- 错误现象：
java.lang.OutOfMemoryError: unable to create new native thread或 CPU 持续 90%+，但业务逻辑几乎不执行 - 真实代价：一个
HashedWheelTimer实例约占用 2–3MB 堆外内存（wheel 数组 + task 链表节点） - 正确做法：整个 JVM 生命周期只初始化 1 个实例，所有连接复用它
tickDuration 和 ticksPerWheel 怎么设才合理
这两个参数决定时间轮的精度与容量上限，不是越小越好，也不是越大越省。对心跳这类 I/O 超时任务，100ms tick 已足够 —— TCP 层重传都动辄几百毫秒，应用层强求毫秒级精度反而增加轮子扫描频率，徒增 CPU 占用。
-
tickDuration = 100（单位MILLISECONDS）：默认值，覆盖 95% 的心跳场景（如 5s/30s 心跳检测） -
ticksPerWheel = 512：默认值，支持最大超时时间 ≈512 × 100ms = 51.2s；若需支持 2 分钟超时，可设为1024（但注意 wheel 数组翻倍） - 避免踩坑：把
tickDuration改成1ms → 扫描频率暴增 100 倍，CPU 空转飙升；把ticksPerWheel设成65536→ 单实例堆外内存涨到 50MB+
如何把心跳任务绑定到连接生命周期上
心跳不是静态任务，必须随 Channel 的创建/关闭动态注册/取消。关键点在于：任务对象要能持有 Channel 引用，且在 Channel.close() 时主动 cancel 对应的 Timeout，否则任务残留会持续触发、引发 NPE 或资源泄漏。
- 示例写法：
Timeout timeout = timer.newTimeout(heartbeatTask, 5, TimeUnit.SECONDS); // 在 ChannelInactive 事件中： if (timeout != null && !timeout.isExpired() && !timeout.isCancelled()) { timeout.cancel(); } - 不要用匿名内部类或 Lambda 直接捕获
Channel：容易导致Channel无法被 GC，尤其在频繁上下线场景下内存缓慢泄漏 - 推荐模式：心跳任务类显式持有一个
ChannelHandlerContext或Channel弱引用（WeakReference），并在run()中先判空再发包
比 HashedWheelTimer 更轻量的替代方案：IdleStateHandler
如果你只是做连接空闲检测（读超时、写超时、全双工空闲），IdleStateHandler 是更优解 —— 它底层仍用 HashedWheelTimer，但已封装好状态机、自动触发 userEventTriggered，且与 ChannelPipeline 深度集成，无需手动管理 Timeout 生命周期。
- 适用场景：
readerIdleTimeSeconds = 30（30 秒没读到数据就断连）、writerIdleTimeSeconds = 45（45 秒没发数据就 ping） - 优势：零额外线程、无 Timeout 对象泄漏风险、支持 per-Channel 独立配置
- 限制：不适用于需要自定义延迟逻辑的场景（如“首次心跳延后 2s 发送”、“第 3 次失败后降级重试”）
真正难的不是启动一个时间轮，而是让十万级任务在同一个轮子上不互相干扰、不堆积、不漏触发 —— 关键在共享实例、克制调参、绑定生命周期。一旦把 HashedWheelTimer 当成“每个连接专属计时器”，问题就已经埋下了。
