peek返回队首元素（不移除、不检查到期），poll仅在到期时移除并返回队首、否则返回null；二者均非阻塞，需用take()实现阻塞等待。

peek 和 poll 在 DelayQueue 中行为不同：未到期时，peek 返回队首元素（不移除），poll 返回 null（不阻塞、不等待）。

peek 不等待，只看不取

DelayQueue.peek() 是非阻塞操作。它直接返回当前队列中“最早可能到期”的元素（即 Delayed 接口实现对象），不管该元素是否已到期。只要队列非空，就返回队首；队列为空则返回 null。它不检查延迟是否到期，也不修改队列状态。

poll 立即尝试，过期才取走

DelayQueue.poll() 也是非阻塞的。它会检查队首元素是否已到期（即 getDelay(TimeUnit.NANOSECONDS) ≤ 0）。如果已到期，就移除并返回该元素；否则直接返回 null，不会等待或阻塞。

• 注意：poll() 不会触发等待，和 take() 的阻塞行为有本质区别
• 若想等待到期再取，应使用 take()，而非 poll()

常见误用场景与建议

开发中容易误以为 poll() 会“等一会儿再判断”，实际它只做一次即时判断。例如：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

立即学习“Java免费学习笔记（深入）”；

• 定时任务调度中，轮询调用 poll() 却没等到元素，可能是因为还没到期，此时应配合 sleep 或改用 take()
• 用 peek() 判断“下一个要处理的是谁”，但不能据此认为它已可执行——仍需手动调用 getDelay() 验证是否到期
• 避免在循环中高频调用 poll() 空转，可考虑结合 Thread.sleep(1) 或使用 ScheduledExecutorService 替代手动轮询

如何安全判断元素是否可用

正确做法是：先 peek() 获取元素，再显式检查延迟：

• Delayed item = queue.peek();
• if (item != null && item.getDelay(TimeUnit.NANOSECONDS)
• 否则说明尚未到期，不可消费

直接依赖 poll() 返回非 null 来判断“可处理”，隐含了“已到期”语义，但逻辑上更清晰的做法仍是主动校验延迟。