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免费学习笔记（深入）”；
<font size="2">public class DelayTask implements Delayed {<br> private final long triggerTime; // 毫秒时间戳，比如 System.currentTimeMillis() + 5000<br> private final String jobId;<br> private final Runnable action;<br><br> public DelayTask(long delayMs, String jobId, Runnable action) {<br> this.triggerTime = System.currentTimeMillis() + delayMs;<br> this.jobId = jobId;<br> this.action = action;<br> }<br><br> @Override<br> public long getDelay(TimeUnit unit) {<br> long remaining = triggerTime - System.currentTimeMillis();<br> return unit.convert(remaining, TimeUnit.MILLISECONDS);<br> }<br><br> @Override<br> public int compareTo(Delayed o) {<br> if (o == this) return 0;<br> if (o instanceof DelayTask) {<br> long diff = this.triggerTime - ((DelayTask) o).triggerTime;<br> if (diff < 0) return -1;<br> if (diff > 0) return 1;<br> return this.jobId.compareTo(((DelayTask) o).jobId); // 防止返回0导致顺序错乱<br> }<br> return Long.compare(this.getDelay(TimeUnit.NANOSECONDS), o.getDelay(TimeUnit.NANOSECONDS));<br> }<br><br> public void execute() { action.run(); }<br>}</font>典型应用场景与使用建议
订单超时自动取消：用户下单后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 简单轻量，适合单机、低频、精度要求不极端的延迟调度；用对了事半功倍，用错了容易掉坑里。
