DelayQueue 是基于 PriorityQueue 的无界阻塞队列,要求元素实现 Delayed 接口,按剩余延迟时间升序排列,支持 take() 阻塞获取和 poll() 非阻塞获取,适用于单机定时任务等场景。

Java 中的 DelayQueue 是一个无界阻塞队列,专门用于存放实现了 Delayed 接口的元素,这些元素只有在延迟时间到期后才能被取出。它底层基于优先队列(PriorityQueue)实现,并配合堆排序保证最早到期的元素始终在队首,非常适合实现定时任务、缓存过期、订单超时关闭等场景。
DelayQueue 的核心机制
DelayQueue 要求队列中的每个元素都实现 Delayed 接口,该接口只有一个关键方法:getDelay(TimeUnit unit),用于返回当前剩余延迟时间(负数表示已到期)。队列内部按延迟时间升序排列,但不支持直接遍历或查找——只能通过 poll() 或 take() 获取已到期元素。
注意:它不是线程安全的“普通队列”,而是阻塞队列,take() 会一直阻塞直到有元素到期;poll() 则立即返回,可能为 null。
- 元素必须实现
Delayed,通常还需重写compareTo()(因底层用PriorityQueue) - 延迟时间以“从现在起还剩多久”计算,单位由调用方指定,务必保持单位一致
- 队列不接受
null元素,也不允许延迟时间为负数(除非已到期,此时getDelay可返回负值) - 多个相同延迟时间的元素,顺序不保证,需在
compareTo中加入唯一标识(如自增ID)避免比较结果为0
手写一个可延迟执行的任务封装
常见做法是定义一个内部任务类,封装业务逻辑、触发时间与唯一标识:
立即学习“Java免费学习笔记(深入)”;
public class DelayTask implements Delayed {
private final long triggerTime; // 毫秒时间戳,比如 System.currentTimeMillis() + 5000
private final String jobId;
private final Runnable action;
public DelayTask(long delayMs, String jobId, Runnable action) {
this.triggerTime = System.currentTimeMillis() + delayMs;
this.jobId = jobId;
this.action = action;
}
@Override
public long getDelay(TimeUnit unit) {
long remaining = triggerTime - System.currentTimeMillis();
return unit.convert(remaining, TimeUnit.MILLISECONDS);
}
@Override
public int compareTo(Delayed o) {
if (o == this) return 0;
if (o instanceof DelayTask) {
long diff = this.triggerTime - ((DelayTask) o).triggerTime;
if (diff < 0) return -1;
if (diff > 0) return 1;
return this.jobId.compareTo(((DelayTask) o).jobId); // 防止返回0导致顺序错乱
}
return Long.compare(this.getDelay(TimeUnit.NANOSECONDS), o.getDelay(TimeUnit.NANOSECONDS));
}
public void execute() { action.run(); }
}典型应用场景与使用建议
订单超时自动取消:用户下单后15分钟未支付,系统自动关单。将订单ID和关单逻辑封装为 DelayTask,插入 DelayQueue;另起一个守护线程循环调用 take() 并执行,即可精准触发。
缓存预热/失效通知:某些本地缓存需在TTL到期前主动刷新,可放入一个比实际TTL略短的延迟任务,在到期前拉取新数据并重置延迟。
限流器中的令牌发放:配合漏桶或令牌桶,用 DelayQueue 管理待发放的令牌时间点,比轮询更省资源。
- 不要在
take()后直接执行耗时操作,建议提交到线程池,避免阻塞队列线程 - 生产环境建议搭配监控(如队列长度、平均延迟偏差),防止任务堆积或系统时间跳变引发异常
- 若需持久化或集群协同,
DelayQueue不适用,应改用 Redis ZSET + 定时扫描,或 XXL-JOB、Quartz 等调度框架
一个小陷阱:系统时间回拨怎么办?
如果服务器时间被手动回调(比如 NTP 同步异常),System.currentTimeMillis() 突然变小,会导致大量任务误判为“已到期”,集中触发。缓解方式包括:
- 用
System.nanoTime()做相对计时(但无法转成绝对时间戳,适合纯延迟场景) - 引入单调时钟包装(如
new AtomicLong(System.nanoTime())自增模拟) - 上线前校验系统时间稳定性,禁止手动修改,依赖可靠 NTP 服务
基本上就这些。DelayQueue 简单轻量,适合单机、低频、精度要求不极端的延迟调度;用对了事半功倍,用错了容易掉坑里。










