PriorityQueue 默认按自然顺序或Comparator排序，仅保证poll()/peek()获取最高优先级元素，遍历结果无序因其底层为堆结构；可靠有序需反复poll()或改用TreeSet。
Java 中 PriorityQueue 默认不是按你“想要的顺序”排序，而是按自然顺序（Comparable）或你传入的 Comparator 排序——它不保证遍历时有序，只保证每次 poll() 或 peek() 拿到的是当前优先级最高的元素。
为什么遍历 PriorityQueue 得不到排序结果？
PriorityQueue 底层是基于堆（最小堆，默认），不是有序数组或平衡树。它的迭代器不按优先级顺序返回元素，而是按内部数组的存储顺序（类似层序遍历堆结构），所以 for (var e : pq) 或 pq.toArray() 的结果看起来“乱序”。
- 这是设计使然，不是 bug；时间复杂度上，维持堆性质比维护全序更高效
- 若需要随时获取全部元素并有序，应改用
TreeSet或显式调用Arrays.sort(pq.toArray()) - 唯一可靠取有序数据的方式：反复
poll()，直到为空
如何自定义比较逻辑（升序/降序/多字段）？
构造时传入 Comparator 是唯一推荐方式。不要依赖 compareTo() 写错方向，也不要后期修改元素再期望队列重排——PriorityQueue 不监听内容变更。
- 基本降序：
new PriorityQueue(Collections.reverseOrder()) - Integer 降序（避免
int溢出）：new PriorityQueue((a, b) -> Integer.compare(b, a)) - 对象多字段：比如
Task先按priority升序，相同时按id降序：new PriorityQueue<>((t1, t2) -> { int c1 = Integer.compare(t1.priority, t2.priority); if (c1 != 0) return c1; return Integer.compare(t2.id, t1.id); // id 降序 });
add() / offer() / poll() / peek() 的行为差异
这些方法看似相似，但异常策略和返回值不同，直接影响容错逻辑：
立即学习“Java免费学习笔记（深入）”；
-
add(e)和offer(e)都插入元素；区别在于：当队列满（有容量限制时，如使用了PriorityBlockingQueue的子类）add()抛IllegalStateException，而offer()返回false——但注意：普通PriorityQueue无容量限制，二者等价 -
poll()：取并删头元素，队列空时返回null -
peek()：只看不删，空时也返回null；别和element()混，后者空时抛NoSuchElementException
常见陷阱与性能提醒
实际用 PriorityQueue 时，最容易栽在“以为它是个排序容器”，或者忽略泛型擦除带来的运行时问题：
- 不能直接存
int、double等基本类型，必须用包装类（Integer、Double），否则编译失败 - 如果元素本身可变（比如插入后修改了影响比较的字段），队列不会自动调整堆结构，后续
poll()可能返回错误顺序的元素 - 初始化时指定初始容量（如
new PriorityQueue(64)）能减少扩容次数，尤其当你预估元素数量较大时 -
remove(Object)是 O(n) 操作（需遍历找匹配项），慎用；如需高效删除任意元素，考虑TreeSet+ 自定义Comparator，或用带索引的第三方结构
真正关键的一点：PriorityQueue 的“优先”只在出队瞬间兑现，它不提供随机访问或全局有序视图。把这点想清楚，很多奇怪现象就不再奇怪了。
