delayqueue要求元素实现delayed接口，否则poll()始终返回null；需用绝对时间戳实现getdelay()和compareto()，并配守护线程消费任务。
DelayQueue 的核心限制：元素必须实现 Delayed 接口
它不是直接塞 Runnable 或时间戳就能跑的队列。你往里放的每个对象，都得自己告诉队列“我还要等多久才到期”。不实现 Delayed，offer() 不报错，但 poll() 永远拿不到——因为比较逻辑崩了。
常见错误现象：poll() 一直返回 null，或 take() 死等不动；调试发现元素的 getDelay(TimeUnit) 总是返回正无穷或负数。
-
getDelay()必须用传入的unit转换，不能硬写MILLISECONDS - 返回值为负数表示已到期，0 表示刚好到期，正数才是剩余延迟（单位由参数决定）
-
compareTo()必须和getDelay()语义一致，否则优先级乱序——比如按到期时间排序，但compareTo却比 ID
怎么让一个任务带延迟并进队：包装成 Delayed 实例
别手写类去继承——用 Delayed + Comparable 组合最稳。典型做法是封装一个带触发时间戳的简单类：
class DelayedTask implements Delayed {
private final long triggerTime; // 绝对时间，毫秒
private final Runnable action;
<pre class="brush:java;toolbar:false;">DelayedTask(long delayMs, Runnable action) {
this.triggerTime = System.currentTimeMillis() + delayMs;
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 other) {
return Long.compare(this.triggerTime, ((DelayedTask) other).triggerTime);
}}
注意点：
- 用绝对时间（
System.currentTimeMillis() + delay）比相对时间更易比大小，也避开了getDelay()多次调用时系统时间漂移带来的误差 -
compareTo()里强转要加类型检查，否则多态插入不同子类会ClassCastException - 如果任务需携带状态（如 ID、参数），就加字段，但别在
getDelay()里做耗时操作——它会被频繁调用
take() 和 poll() 的行为差异直接影响线程模型
这两个方法看着像，实际调度逻辑完全不同：take() 是阻塞等待，直到有任务到期；poll() 是立即返回，没到期就给 null。选错会导致 CPU 空转或线程卡死。
使用场景：
- 后台单线程消费：用
take()，省心，不占 CPU，适合长期运行的调度器 - 非阻塞轮询（比如 Netty 事件循环里）：必须用
poll()，配合短间隔 sleep，否则线程停不下来 - 想取一个但不想等？用
poll(0, TimeUnit.NANOSECONDS)，效果等价于无参poll()
性能影响：take() 内部用 Condition.awaitNanos()，唤醒精度依赖系统定时器；高频 poll() 而不 sleep 会导致 100% CPU 占用。
DelayQueue 不是定时器替代品：没自动执行、没线程管理
它只是个“能按时间排序+延迟弹出”的集合。把任务塞进去，不会自动 run；没有线程帮你 take() 并执行；也不支持取消、重复、Cron 表达式。
容易踩的坑：
- 忘记启动消费线程——光
offer()一堆DelayedTask，啥也不会发生 - 消费线程异常退出后没重试机制，后续任务全积压
- 任务执行中抛异常，未捕获会导致消费线程终止，整个队列挂起
- 误以为它线程安全＝可并发执行任务——其实
take()是线程安全的，但任务内部逻辑仍需自己同步
真正要用起来，至少得配一个 while + try-catch 的守护线程，且 action.run() 必须包在 try 里。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
