PriorityQueue.peek() 返回 null 的常见原因：队列为空时返回 null（非异常），泛型中 null 是合法值，需用 isEmpty() 判空；自定义比较器逻辑错误、多线程下非原子操作及未校验空值易致 NullPointerException。

peek() 返回 null 的常见原因

PriorityQueue.peek() 在队列为空时返回 null，不是抛异常——这点和 poll() 不同。很多开发者在未判空就直接调用 .toString() 或解包，结果触发 NullPointerException。

• 务必在调用前检查 queue.isEmpty()，尤其在循环或回调中反复读取时
• 如果使用泛型（如 PriorityQueue<integer></integer>），注意 null 是合法值（除非你禁用了），所以 peek() == null 不一定代表队列空——得结合 isEmpty() 判断
• 自定义比较器时，若比较逻辑返回 0 但对象实际不等，peek() 仍只返回“逻辑上最小”的那个，不会报错也不会警告

peek() 和 poll() 的行为差异必须分清

peek() 是只读操作，不改变队列结构；poll() 才真正移除并返回头元素。两者时间复杂度都是 O(1)，但误用会破坏业务逻辑。

• 需要“预览再决定是否处理”时，用 peek() + 条件判断 + （可能的）poll()
• 写成 if (queue.peek() != null && meetsCondition(queue.peek())) { queue.poll(); } 是安全模式
• 千万别用 queue.peek().equals(queue.poll()) 做校验——poll() 已经把元素拿走了，下次 peek() 是新元素

泛型类型与 compareTo() 实现对 peek() 结果的影响

PriorityQueue 的“最高优先级”由其内部堆序决定，而堆序依赖元素的自然顺序（实现 Comparable）或外部 Comparator。如果定义有误，peek() 返回的就不是你预期的那个。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 使用 String、Integer 等内置类型时，peek() 返回字典序最小或数值最小的元素（默认最小堆）
• 自定义类必须正确重写 compareTo()，且不能在比较过程中修改对象状态，否则后续 peek() 行为不可预测
• 若需最大堆，别改 compareTo()，而是传入 Comparator.reverseOrder() 构造队列：new PriorityQueue(Comparator.reverseOrder())

多线程环境下 peek() 不是原子操作

PriorityQueue 本身**不保证线程安全**。peek() 虽然是 O(1) 且不修改结构，但如果其他线程同时在 add() 或 poll()，你拿到的 peek() 结果可能瞬间失效。

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

• 不要依赖 “peek() 非空 → 紧接着 poll() 一定成功” 这个假设
• 高并发场景下，要么用 PriorityBlockingQueue（它的 peek() 是线程安全的），要么用显式锁包裹 peek()+poll() 组合
• 注意：即使加了锁，peek() 返回的仍是引用，若对象可变，其他线程仍可能在你读字段时改掉它

实际用的时候，最常被忽略的是空值判断和线程安全边界——尤其是把单线程逻辑直接搬到异步任务里跑，peek() 看似简单，出问题却很难复现。