DelayQueue 必须存实现 Delayed 接口的对象，需同时重写 getDelay 和 compareTo 方法；取任务必须用 take() 阻塞等待，消费应单线程取出后交由业务线程池异步处理，并配合外部存储实现持久化与幂等关单。
DelayQueue 不能直接存普通对象，必须实现 Delayed 接口
很多人往 DelayQueue 里塞 Order 实例后发现任务根本不触发，原因很简单：它只认实现了 Delayed 接口的对象。这个接口强制你提供两个东西：getDelay(TimeUnit) 和 compareTo(Delayed)。
常见错误是只重写 getDelay，忘了 compareTo —— 这会导致队列内部排序失败，元素可能永远不被取出。
-
getDelay返回剩余延迟时间（负数表示已过期），单位必须和传入的TimeUnit一致 -
compareTo必须基于剩余延迟时间比较，不能用业务 ID 或创建时间硬比 - 别在
getDelay里做耗时操作（比如查数据库），否则阻塞队列轮询
public class OrderDelayTask implements Delayed {
private final long triggerTime; // 绝对触发时间戳，毫秒
private final String orderId;
public OrderDelayTask(String orderId, long timeoutSeconds) {
this.orderId = orderId;
this.triggerTime = System.currentTimeMillis() + timeoutSeconds * 1000;
}
@Override
public long getDelay(TimeUnit unit) {
return unit.convert(triggerTime - System.currentTimeMillis(), TimeUnit.MILLISECONDS);
}
@Override
public int compareTo(Delayed o) {
return Long.compare(this.triggerTime, ((OrderDelayTask) o).triggerTime);
}}
从 DelayQueue 取任务必须用 take()，不能用 poll()
poll() 是非阻塞的，立刻返回 null 或头结点；而订单超时这种场景，你希望线程“等着”，直到有任务真正到期。用 poll() 就得自己写 while + sleep 循环，极易出错且浪费 CPU。
更隐蔽的问题是：如果用 poll(1, TimeUnit.SECONDS) 这类带超时的版本，一旦队列为空，它会频繁唤醒线程，吞吐量上不去，还掩盖了实际延迟精度问题。
-
take()会阻塞直到队首元素到期，天然适配“守着队列等超时”的语义 - 注意：
take()可能被中断，必须捕获InterruptedException并恢复中断状态 - 不要在一个线程里反复调用
take()后再做耗时处理（比如关单+发消息），这会卡住整个队列消费
单线程消费 DelayQueue 无法应对高并发关单，但加多线程又破坏顺序性
一个 DelayQueue 本身是线程安全的，但它的消费逻辑不是。如果你开多个线程同时 take()，虽然吞吐上去了，但同一时刻可能有多个线程拿到不同订单去关单——这本身没问题；但如果关单涉及库存回滚、状态校验等强一致性操作，就容易出现“超时关单”和“用户主动支付成功”打架的情况。
典型表现是日志里看到“订单已支付，无法关闭”这类报错，说明关单动作没做幂等判断。
- 推荐做法：单线程消费
DelayQueue，取出任务后丢进业务线程池异步处理 - 每个关单操作必须先查最新订单状态（不能只信队列里的快照），再决定是否执行
- 给关单逻辑加分布式锁或数据库乐观锁（比如
UPDATE order SET status=... WHERE id=? AND status='unpaid'）
DelayQueue 不持久化，JVM 崩溃后所有待处理任务丢失
这是最容易被忽略的一点：它纯内存结构。服务重启、OOM、机器宕机，队列里还没到期的订单全没了——用户下单后啥也没发生，钱却扣了，客服电话马上打爆。
有人想用序列化把队列 dump 到磁盘，但 DelayQueue 内部结构复杂，反序列化后 getDelay 时间基准错乱，基本不可行。
- 生产环境必须搭配外部存储：把待关单订单写入 Redis（带过期时间）或数据库（status=‘pending_close’ + close_time 字段）
- 启动时扫描数据库/Redis，把未过期的记录重新塞进
DelayQueue - 关单成功后，必须同步删除存储中的记录，避免重复触发
真正的难点不在怎么塞进队列，而在于“什么时候删”和“删不掉怎么办”。比如数据库删失败，得有补偿任务定期捞取超时未关单的脏数据。
