HashedWheelTimer适合单机百万级轻量延时任务（如心跳检测），但不适用于订单关闭等强一致性场景，因其任务仅存JVM内存、不可持久化、无容错与状态协同能力。
HashedWheelTimer 可以在单机环境下高效管理百万级延时任务，但**仅限于非关键、可丢失、低延迟要求的轻量场景**，比如网关层倒计时提示、连接空闲检测、本地缓存过期清理。它不能用于订单自动关闭这类强一致性业务——因为任务全在 JVM 堆内存里，服务重启、扩容缩容、OOM 崩溃都会导致未触发任务永久丢失。
为什么单机 HashedWheelTimer 适合“百万级”数量，却不适合“订单关闭”
它的高性能来自结构设计：
- 底层是固定大小环形数组（如 512 槽）+ 每槽挂链表，插入/取消时间复杂度为 O(1)
- 单工作线程驱动指针轮转，避免线程竞争和频繁调度开销
- 任务不依赖外部存储，无序列化、网络、IO 等瓶颈，吞吐轻松达数十万/秒
但这也意味着：
- 所有任务只存在当前 JVM 内存中，不可持久化
- 没有失败重试、幂等控制、状态回溯能力
- 无法感知订单真实状态（是否已支付、是否已取消），也无法联动库存、优惠券等下游系统
若坚持用在单机订单场景，必须明确边界与兜底逻辑
只能作为辅助手段，绝不能承担主流程责任。例如：
- 下单成功后，在网关或接入层启动一个 HashedWheelTimer 倒计时（如 15 分钟），到期发起一次 HTTP 请求到订单服务，查询该订单是否仍为「待支付」
- 这个请求只是触发一次「检查动作」，不是执行取消；真正的取消必须由订单服务走完整状态机 + 补偿机制完成
- 同时必须搭配 Redis ZSet 或 Kafka 延迟消息作为主通道，HashedWheelTimer 仅作用户体验优化（如提前弹窗提醒）
典型单机配置与使用要点
以 Netty 的 HashedWheelTimer 为例：
- tickDuration：建议设为 100ms，精度够用且不过度轮转
- ticksPerWheel：设为 512 或 1024，覆盖常见延时范围（如 15 分钟 = 900 秒 → 需 ≥ 9000 槽，此时应增大 tickDuration 或改用多层轮）
- 线程模型：务必指定独立线程工厂，避免阻塞 I/O 线程
- 任务体：必须轻量、无阻塞、不抛异常；耗时操作要异步提交到业务线程池
-
取消机制：下单后用户立即支付，需显式调用
timeout.cancel()，否则任务仍会触发
真正落地时，单机方案要配合分布式基座
即使部署单实例服务，也要按分布式思维设计：
- 订单写入时，同步写入 Redis ZSet（score = 超时时间戳，member = 订单 ID）
- 另起一个常驻扫描任务（每 200ms 查一次 ZSET 中 score ≤ now 的前 100 条），加分布式锁后批量处理
- HashedWheelTimer 可在此扫描任务内部用于控制「单次扫描耗时上限」或「重试间隔」，而非直接绑定订单生命周期
