用delayqueue实现订单超时取消，核心是订单实现delayed接口并基于system.nanotime()计算剩余延迟，由独立线程take()获取到期订单后校验状态再执行取消；需注意入队时机、幂等性及jvm重启丢失问题，须结合db或消息队列持久化兜底。
用 DelayQueue 实现订单超时取消，核心是让订单对象自己“算好时间”，到期自动触发取消逻辑，不依赖外部轮询或定时任务。
订单对象必须实现 Delayed 接口
DelayQueue 只能存实现了 Delayed 接口的对象。订单类（如 Order）需重写两个方法：
- getDelay(TimeUnit unit)：返回距离当前时间还剩多少延迟（单位由参数指定）。若结果 ≤ 0，表示已到期，会被 DelayQueue 的 take() 拿走
- compareTo(Delayed other)：用于队列内部排序，通常按剩余延迟时间升序排（越早到期越靠前）
关键点：延迟时间应基于“订单创建时间 + 超时阈值”计算，比如 30 分钟未支付，则到期时间为 System.nanoTime() + 30L * 60 * 1_000_000_000，避免使用 currentTimeMillis()（精度低、可能回拨）。
启动一个单独的消费者线程监听队列
DelayQueue 是线程安全的，但本身不执行任何动作。你需要一个长期运行的线程，持续调用 take() 阻塞等待到期订单：
-
Order order = delayQueue.take();—— 一拿到就说明已超时 - 接着校验订单当前状态（是否已支付、已取消等），防止重复处理
- 执行业务取消逻辑：更新数据库状态、释放库存、发通知等
建议用 ThreadFactory + ThreadPoolExecutor 管理该线程，避免裸写 while(true) + sleep；同时加 try-catch 包裹 take()，防止异常中断消费。
订单入队时机要精准且幂等
不是下单就立刻入队，而是当订单进入“待支付”状态（例如调用 createOrder 成功、生成支付链接后）才调用 delayQueue.put(order)。
- 如果用户中途主动取消，需从队列中移除该订单 —— 但 DelayQueue 不支持高效删除，推荐改用 remove(Object)（O(n) 查找，适合低频取消场景）
- 更稳妥的做法：入队时不放完整订单，而放轻量级 Token（如 orderId），并在 take 后先查库确认状态再操作，天然支持幂等
注意可靠性与边界问题
DelayQueue 运行在 JVM 内存中，进程重启会丢失所有待处理订单。生产环境必须配合持久化方案：
- 订单创建/状态变更时，同步写入 DB 或消息队列（如 Kafka）作为兜底
- 应用启动时扫描 DB 中“待支付且创建时间 + 30min
- 避免把高延迟（如 24 小时）订单全塞进 DelayQueue，可能引发内存压力和精度漂移，长周期任务建议交给 XXL-JOB 或 Redis ZSet
不复杂但容易忽略。
