peek()在队列为空时返回null而非抛异常；使用前必须判空，且多线程下无法保证peek()后元素仍存在，LinkedList按FIFO返回首元素，PriorityQueue返回堆顶优先级最高元素，ConcurrentLinkedQueue.peek()不保证实时性。
peek() 返回 null 时到底发生了什么
peek() 在队列为空时返回 null，不是抛异常。这点和 poll() 不同——后者也返回 null（空队列时），但会移除元素；而 peek() 纯粹只读。常见误判是把 null 当成业务数据，结果后续调用 .toString() 或解包时触发 NullPointerException。
实际使用前必须显式判空：
if (taskQueue.peek() != null) {
System.out.println("下一个任务是：" + taskQueue.peek().getName());
}
尤其在多线程环境下，peek() 和后续操作之间可能有其他线程已 poll() 掉该元素，所以「预览后立刻处理」不能靠两次独立调用保证原子性。
LinkedList 和 PriorityQueue 的 peek() 行为差异
LinkedList 实现 Queue 接口时，peek() 时间复杂度是 O(1)，直接返回头节点；而 PriorityQueue 的 peek() 虽然也是 O(1)，但它返回的是「逻辑上优先级最高」的元素，不一定是插入顺序最早的——这点容易被忽略，尤其当任务按时间戳排序却误以为 peek() 总是最早入队的那个。
立即学习“Java免费学习笔记（深入）”；
关键区别在于：
-
LinkedList：FIFO，peek()≡ 最早入队项 -
PriorityQueue：按Comparable或Comparator排序，peek()≡ 当前堆顶（最小或最大）
如果业务需要严格按提交顺序预览，别用 PriorityQueue；如果需要按优先级调度，就别假设 peek() 反映插入时间。
ConcurrentLinkedQueue.peek() 的特殊限制
ConcurrentLinkedQueue 的 peek() 是线程安全的，但文档明确写了：它不保证返回的是「当前时刻」的队首。由于无锁实现的快照特性，调用瞬间可能刚被另一个线程 poll() 掉，返回值仍是旧引用（但该引用可能已被逻辑移除）。更麻烦的是，它不抛异常也不阻塞，静默返回过期节点的值。
应对策略只有两个：
- 接受「最终一致性」，仅用于低精度监控（如后台打印“当前疑似待处理任务数”）
- 改用
BlockingQueue子类（如ArrayBlockingQueue），配合peek()+ 业务层重试逻辑
别试图靠 ConcurrentLinkedQueue.peek() == null 判断队列是否真的空——它可能只是刚好错过一次修改。
peek() 后想安全消费？得自己加同步或换接口
单纯 peek() 解决不了「预览后执行」的竞态问题。比如 UI 层想显示下一个任务并提供「跳过」按钮，用户点击时需确保那个任务还在队列里。这时不能写：
Task next = queue.peek(); // 可能已被其他线程取走
if (next != null && userSkipped(next)) {
queue.poll(); // 但 next 可能已不是队首
}
正确做法取决于场景：
- 单线程：直接
poll()+ 回滚逻辑（如失败则offer()回去） - 多线程且需强一致性：用
BlockingQueue.poll(timeout, unit)替代peek()，把「预览+获取」合并为一次原子操作 - 需要条件跳过：考虑用
TransferQueue或外部锁（如ReentrantLock包裹peek()+poll()）
最常被忽略的一点：没有万能的「安全预览」API，peek() 的设计本意就是轻量、非阻塞、不保证实时性——把它当「快照提示」用，别当「事务锁」用。
