图 1：本文封面，时间轮的哈希分桶与 tick 指针推进示意。
先说明属性：这是一篇经典题解析，题目出自本地历史面试资料整理，与任何公司的当前招聘无关。「Netty 的时间轮（HashedWheelTimer）用法、实现原理、会不会不准时、怎么解决」是一个三连问：前半问数据结构，后半问工程坑。它背后的场景很实在——一个网络框架要同时维护成千上万条连接的空闲检测、握手超时、重试定时，用「每个任务一个线程」或「每次扫描全量任务」都扛不住这个量级。
一句话结论：用哈希分桶把任务的增删降到近似 O(1)，再用单个 worker 线程按固定节奏逐格推进指针，到期桶整桶处理。
数据结构：一张哈希表，key 是到期时间。
Netty 官方 Javadoc 对这个类的定位写得很直白：一个「为近似 I/O 超时调度优化」的定时器，本质是一张以任务截止时间为哈希值的哈希表。轮子是一个数组，默认 512 个桶（wheelSize），每个桶挂一条任务链表；每格代表一个 tick 的时长，默认 100 毫秒（tickDuration），一圈下来 512 × 100 ms = 51.2 秒。新任务进来时先算出到期在第几个 tick，桶位就是 tick 数 & (wheelSize − 1)——桶数取 2 的幂，取模退化成一次位运算；如果延迟超过一圈，再记一个「剩余圈数」。插入是哈希加挂链表，取消是从链表里摘节点，两者都近似 O(1)，这就是它能扛住海量任务的根本原因。这套设计源自 Varghese 与 Lauck 关于哈希与分层时间轮的经典论文，Netty 的文档里也注明了出处。
推进机制：一个线程拨完整张轮。
HashedWheelTimer 内部只有一个 worker 线程：每 100 毫秒醒来一次，指针前进一格，把当前桶的链表整桶取出来遍历——剩余圈数大于 0 的任务圈数减一、留到下一轮；圈数为 0 的才真正执行。注意官方文档的另一个提醒：这个类每次实例化都会新建线程，所以全应用应该共享一个实例，最常见的误用就是给每条连接 new 一个时间轮，线程数直接爆炸。
用一个 8 桶的迷你时间轮把这套机制跑一遍（JDK 21，javac MiniWheel.java && java MiniWheel），三个任务分别设定 250 ms、800 ms、1250 ms：
入桶: 任务A 设定 250ms -> 第 3 个 tick, 桶位 3, 剩余圈数 0
入桶: 任务B 设定 800ms -> 第 8 个 tick, 桶位 0, 剩余圈数 1
入桶: 任务C 设定 1250ms -> 第 13 个 tick, 桶位 5, 剩余圈数 1
tick 3 (t= 300ms): 桶 3 整桶处理, 任务A 触发, 误差 50ms
tick 8 (t= 800ms): 桶 0 整桶处理, 任务B 触发, 误差 0ms
tick 13 (t=1300ms): 桶 5 整桶处理, 任务C 触发, 误差 50ms
输出里藏着两个考点：其一，800 ms 的任务恰好延迟一整圈，入桶时圈数为 1，要等指针第二次转到桶 0 才触发——圈数机制就是为「延迟超过一圈」的任务准备的；其二，250 ms 的任务实际在 300 ms 触发，这就是标题里「近似」二字的分量。
坑位一：精度最多粗糙一个 tick。
任务只可能在 tick 边界上被处理，实际触发时刻与设定时刻最多差一个 tickDuration。想提高精度只能缩短 tick，代价是 worker 醒得更频繁、空转开销变大。好在网络场景的超时检测本来就不要求精确——空闲 30 秒的连接在 30.05 秒断开毫无影响——这正是默认 100 ms 在多数情况下够用的原因。真要高精度定时，时间轮就不是合适的工具。
坑位二：积压会拖累整轮，耗时任务必须交出去。
worker 只有一个线程，如果某个桶里堆了几千个任务，或者某个任务的执行逻辑本身很慢，这个 tick 的处理时间就被拉长，后面所有 tick 全部顺延——这就是三连问里「调用不够准时」的主要来源。标准解法是把到期处理拆成两层：时间轮只做「到期判断」这种极轻的活，真正的业务逻辑（发消息、关连接、跑重试）立刻扔给业务线程池执行，worker 绝不在轮子里久留。
图 2：参数与定位公式、三步工作流程与两个经典坑位。
面试现场的答题结构。
先给定位「为海量近似超时调度优化的定时器」，再讲数据结构：512 桶哈希表加任务链表，桶位一次位运算算出，增删近似 O(1)。然后讲推进：单 worker 每 100 ms 拨一格，到期桶整桶处理，超圈任务靠圈数记账。接着主动交代两个坑——精度粗糙一个 tick、积压阻塞整轮——并给出解法：缩短 tick 换精度（有限度），耗时任务移交业务线程池。最后补一句实例共享的注意事项收尾。这个系列另有一篇文章把时间轮放进「定时方案横向选型」的坐标系里和 Timer、DelayQueue、Quartz 对比，感兴趣的可以接着看。你在项目里用过时间轮或类似的定时结构吗？踩过积压的坑吗？欢迎聊聊。