DelayQueue是Java中基于优先级队列实现的无界阻塞延时队列，要求元素实现Delayed接口（含getDelay和compareTo方法），仅到期任务可被take()获取，需配合外部线程消费，适用于单次延时场景如订单关单。
DelayQueue 是 Java 并发包（java.util.concurrent）中一个无界阻塞队列，专门用于实现**延时任务调度**。它内部基于优先级队列（PriorityQueue），元素必须实现 Delayed 接口，通过 getDelay(TimeUnit) 决定何时“到期”，只有到期的元素才能被 poll() 或 take() 获取。
DelayQueue 的核心要求：必须实现 Delayed 接口
所有放入 DelayQueue 的元素都得是 Delayed 的子类实例。这个接口只定义了两个方法：
-
long getDelay(TimeUnit unit)：返回当前剩余延迟时间（单位由参数指定）。若 ≤ 0，表示已到期； -
int compareTo(Delayed other)：用于队列内部排序，通常按到期时间升序排列（越早到期排越前）。
注意：不能直接用 new Date().getTime() + delayMs 做比较，因为 compareTo 必须与 getDelay 逻辑一致，否则排序和出队行为会错乱。
一个典型的 Delayed 任务封装示例
比如封装一个带业务逻辑的延时任务：
立即学习“Java免费学习笔记（深入）”；
public class DelayTask implements Delayed {
private final long expireTime; // 毫秒时间戳，到期时间
private final Runnable task;
public DelayTask(long delayMs, Runnable task) {
this.expireTime = System.currentTimeMillis() + delayMs;
this.task = task;
}
@Override
public long getDelay(TimeUnit unit) {
long remaining = expireTime - System.currentTimeMillis();
return unit.convert(remaining, TimeUnit.MILLISECONDS);
}
@Override
public int compareTo(Delayed other) {
return Long.compare(this.expireTime, ((DelayTask) other).expireTime);
}
public void execute() {
if (task != null) task.run();
}}
这样构造出来的任务，放进 DelayQueue 后会按 expireTime 自动排序，最早到期的在队首。
启动一个消费者线程持续取任务执行
DelayQueue 本身不执行任务，只是“存+等+放”。你需要单独起一个线程（或用线程池）来 take() 已到期任务并执行：
-
take()是阻塞方法：没有到期任务时会一直等待，直到有任务到期才返回； - 每次
take()返回的是**已到期**的任务，无需再判断时间； - 建议用
while (!Thread.currentThread().isInterrupted())包裹，支持优雅关闭。
DelayQueuequeue = new DelayQueue<>(); // 启动消费线程 new Thread(() -> { while (!Thread.currentThread().isInterrupted()) { try { DelayTask task = queue.take(); // 阻塞直到有任务到期 task.execute(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } }).start();
// 添加延时任务（5秒后执行） queue.offer(new DelayTask(5000, () -> System.out.println("Hello after 5s!")));
注意事项和常见坑点
- 不是定时器替代品：DelayQueue 不支持周期性任务（如每5秒执行一次），只适合“单次延时触发”；
- 内存泄漏风险：如果任务长期不被 take，又没被外部引用，GC 能回收；但若消费者停了、任务堆积，可能吃光内存；
-
精度依赖系统时钟：getDelay 基于
System.currentTimeMillis()，受系统时间调整影响（NTP 同步、手动改时间都会干扰）；高精度场景建议用System.nanoTime()+ 相对计算； - 不保证绝对准时：take 是唤醒后执行，线程调度、GC、锁竞争都会带来毫秒级偏差，不适合亚毫秒级强实时场景。
基本上就这些。DelayQueue 简单轻量，适合中小规模、非强实时的延时通知、缓存清理、订单超时关单等场景。真要支撑高并发、高可用、可持久化、可观测的延时任务，还是得上 Quartz、XXL-JOB 或 Redis + SortedSet 方案。
