PriorityQueue适合需频繁取最值且插入频繁的场景，如任务调度、Top-K问题、Dijkstra算法、合并K个有序链表；它不保证遍历有序，底层数组不缩容，非线程安全，依赖正确Comparator。
PriorityQueue 适合解决哪些实际问题
它不是用来“排序整个集合”的，而是当你需要反复取最小（或最大）元素、且插入频繁时的最优选择。比如任务调度里按优先级取下一个要执行的任务，或者 Top-K 问题中维护当前最大的 K 个数。
常见错误现象：PriorityQueue 的 peek() 或 poll() 返回的不是你“按插入顺序”期待的那个元素，而是堆顶——这恰恰是它设计目的，不是 bug。
- 使用场景：实时数据流中找前 N 大/小值、Dijkstra 算法中的待处理节点选择、合并 K 个有序链表
- 不能替代
TreeSet或Arrays.sort()：它不保证遍历时有序，iterator()不按优先级顺序返回 - 默认是最小堆；要最大堆得传
Comparator.reverseOrder()或自定义比较器
为什么 poll() 后 size 减一但内部数组没缩容
PriorityQueue 底层用 Object 数组实现动态堆，扩容靠 grow()，但缩容完全不发生。这是为了性能妥协：避免频繁内存重分配。
影响很实际：如果你往队列里塞了 100 万个元素，又逐个 poll() 干净，内部数组依然占着约 128 万容量（具体取决于初始容量和增长策略），内存不会自动还回去。
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 如果明确知道后续不会再大量插入，可以新建一个空
PriorityQueue，再把剩下元素addAll()过去（但注意这会重建堆） - 别依赖
size()推断内存占用，要看实际元素数，而不是底层数组长度 - 在内存敏感场景（如长时间运行的中间件），这点容易被忽略，导致 OOM 风险比预期高
Comparator 写错会导致 poll() 返回异常结果
只要比较器违反“传递性”或返回 0 表示两个逻辑上不等的元素，堆结构就可能损坏——poll() 可能跳过某些元素，甚至死循环（极少见但有报告）。
典型翻车点：用浮点数直接比较（a == b）、在比较器里读可变对象字段但对象中途被改、或漏处理 null。
- 安全写法：对可能为 null 的字段，用
Objects.compare(a, b, Comparator.nullsLast(Comparator.naturalOrder())) - 避免在比较器里调用外部 IO 或耗时计算，堆操作本身要求 O(log n) 时间，否则整体性能坍塌
- 测试时别只喂相同值，一定要混入边界值、null、浮点误差值来验证比较器是否稳定
PriorityQueue 不是线程安全的
所有方法（offer()、poll()、peek()）都不加锁。多线程并发读写必然出错：可能抛 ConcurrentModificationException，也可能静默返回错误结果（比如漏掉某个元素）。
别想着“我只读不写就没事”——poll() 和 offer() 都会修改堆结构，而 iterator() 是弱一致性快照，无法保证看到最新状态。
- 需要并发安全？用
PriorityBlockingQueue，它支持阻塞式插入/取出，且所有操作线程安全 - 如果只是多个线程各自维护自己的队列，那就没问题；共享一个实例就必须加锁或换并发容器
- Spring 或其他框架里自动注入的
PriorityQueueBean，默认就是单例共享的，这点特别容易踩坑
堆的不变性是隐式的，不出错时你感觉不到它存在；一旦比较器、并发或内存假设出问题，表现往往是“偶尔少一个元素”或“顺序乱了”，很难复现。盯住那几个关键点比事后 debug 更省时间。
