DelayQueue 是 Java 中基于 Delayed 接口实现的无界阻塞队列，用于存储延时任务，需配合消费者线程调用 take() 获取并执行到期任务，不自动调度且不持久化。
DelayQueue 是 Java 并发包中专为延时任务设计的无界阻塞队列，它本身不支持直接“执行”任务，而是提供一个线程安全的、按到期时间排序的存储结构；真正实现延时任务调度，需要配合消费者线程（如单独线程或线程池）不断轮询并执行已到期的任务。
DelayQueue 的核心要求：元素必须实现 Delayed 接口
要放入 DelayQueue 的对象，必须实现 Delayed 接口，该接口继承自 Comparable，强制要求两个方法：
- getDelay(TimeUnit unit)：返回当前剩余延迟时间（正数表示未到期，0 或负数表示已到期）；单位由参数指定，需注意单位换算一致性；
- compareTo(Delayed other)：用于队列内部排序，通常比较的是各自 getDelay(TimeUnit.NANOSECONDS) 的结果，确保最早到期的排在队首。
常见写法是封装一个带触发时间戳（如 System.nanoTime() + delayNanos）的包装类，getDelay 中用当前纳秒时间减去该戳，返回差值。
典型使用模式：生产者 + 单消费者线程
DelayQueue 本身是阻塞队列，但不自动触发任务。标准用法是：
立即学习“Java免费学习笔记（深入）”；
- 生产者线程调用 offer(task) 添加延时任务；
- 单独启动一个消费者线程，循环调用 take() —— 这个方法会阻塞直到队首任务到期，然后移出并返回；
- 拿到任务后，在消费者线程中执行其业务逻辑（例如调用 task.run() 或 submit 到线程池）。
⚠️ 注意：不要在 take() 后再做“是否已过期”的二次判断（take 已保证到期），也不建议用 poll() 配合 sleep 轮询——既浪费 CPU 又不精确，违背 DelayQueue 设计初衷。
实际例子：简易订单超时关闭任务
假设下单后 30 分钟未支付，自动关闭订单：
class OrderTimeoutTask implements Delayed {
private final long triggerAtNanos;
private final String orderId;
<pre class="brush:php;toolbar:false;">OrderTimeoutTask(String orderId, long delayMs) {
this.orderId = orderId;
this.triggerAtNanos = System.nanoTime() + TimeUnit.MILLISECONDS.toNanos(delayMs);
}
@Override
public long getDelay(TimeUnit unit) {
long nanosLeft = triggerAtNanos - System.nanoTime();
return unit.convert(nanosLeft, TimeUnit.NANOSECONDS);
}
@Override
public int compareTo(Delayed o) {
return Long.compare(this.triggerAtNanos, ((OrderTimeoutTask) o).triggerAtNanos);
}
void execute() {
System.out.println("订单 " + orderId + " 超时，执行关闭逻辑");
// 调用订单服务关闭接口...
}}
消费者线程示例：
DelayQueue<OrderTimeoutTask> queue = new DelayQueue<>();
new Thread(() -> {
while (!Thread.currentThread().isInterrupted()) {
try {
OrderTimeoutTask task = queue.take(); // 自动阻塞等待到期
task.execute();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
break;
}
}
}).start();
<p>// 生产者：下单时提交任务
queue.offer(new OrderTimeoutTask("ORD123", 30 <em> 60 </em> 1000)); // 30分钟注意事项与局限性
- DelayQueue 是内存队列，进程重启后任务丢失，生产环境需结合 Redis ZSet、数据库定时任务等持久化方案；
- 所有任务都由同一个消费者线程串行执行，高并发大量延时任务时可能成为瓶颈，可考虑多消费者（但需注意顺序性和重复执行风险）；
- 任务对象应尽量轻量，避免在 getDelay 或 compareTo 中做耗时操作；
- 系统时间被人为调整（如 NTP 同步、手动改时间）会影响延迟精度，nanoTime() 相对更可靠，但无法完全规避。
不复杂但容易忽略：DelayQueue 是工具，不是调度器。它的价值在于精准、低开销地管理“何时就绪”，而“谁来执行”和“怎么持久化”得由你来设计补全。
