priorityqueue默认是最小堆，队首返回最小元素；需显式传comparator.reverseorder()才能实现最大堆；自定义对象必须实现comparable或提供comparator，否则抛classcastexception。
PriorityQueue默认是最小堆还是最大堆
PriorityQueue 默认是最小堆 —— 也就是队首（peek() 或 poll()）返回的是最小元素。这不是靠文档“约定”，而是由其底层比较逻辑决定的：当没传 Comparator 时，它要求元素实现 Comparable 接口，并调用 compareTo()，自然按升序排。
- 如果你存的是
Integer、String这类自带比较逻辑的类型，直接 new 就是最小堆 - 想要最大堆？必须显式传
Comparator.reverseOrder()，比如：new PriorityQueue(Comparator.reverseOrder()) - 别指望靠“插入顺序”或“重写 toString()”来改变排序行为 —— 它只看
compareTo()或构造时给的Comparator
自定义对象怎么进PriorityQueue不报ClassCastException
报 ClassCastException: xxx cannot be cast to java.lang.Comparable 是最常见错误，本质是 PriorityQueue 在建堆时尝试调用 compareTo()，但你的类没实现 Comparable，也没配 Comparator。
- 必须二选一：
- 实现
Comparable接口，重写compareTo()（注意 null 和相等情况的处理） - 或在构造时传
Comparator，例如：new PriorityQueue((a, b) -> Integer.compare(a.priority, b.priority))
- 实现
- 别用
==比较引用类型字段；别在compareTo()里抛异常或返回非 int 值 - 如果字段可能为 null，用
Objects.compare(a.field, b.field, Comparator.nullsLast(Comparator.naturalOrder()))更安全
poll() 和 peek() 的区别和误用场景
peek() 只看队首不移除，poll() 看完还弹出 —— 表面简单，但容易在循环或条件判断里搞混。
- 循环取最小值时，写成
while (!pq.isEmpty()) { process(pq.peek()); pq.poll(); }是错的：如果process()抛异常，poll()没执行，下次又会重复处理同一个元素 - 正确做法是先
poll()再处理：while (!pq.isEmpty()) { process(pq.poll()); } -
peek()适合做“预检”，比如判断是否满足某个阈值再决定是否取出：if (pq.peek() != null && pq.peek().value > 100) { ... } - 注意：
peek()对空队列返回null，poll()也返回null（不是抛异常），所以判空必须用isEmpty()，不能靠peek() == null做唯一依据（除非你确定不会存 null 元素）
PriorityQueue不是线程安全的，多线程下怎么避免数据错乱
PriorityQueue 是非线程安全的，多个线程同时 offer() / poll() 会导致堆结构损坏、NullPointerException、甚至无限循环 —— 不是偶尔出错，是大概率崩。
立即学习“Java免费学习笔记（深入）”；
- 别用
Collections.synchronizedCollection(new PriorityQueue())：它只同步单个方法，堆操作（如offer后需调整结构）需要跨方法原子性，这样包一层没用 - 正确方案只有两个：
- 用
PriorityBlockingQueue（无界、线程安全、基于 CAS + LockSupport 实现） - 或外层加显式锁，比如
synchronized(pq) { pq.offer(item); }，但要注意锁粒度，别把耗时操作包进去
- 用
- 如果只是读多写少，且能接受“最终一致”，也可以考虑用
ConcurrentSkipListSet替代（它天然有序、线程安全，但不支持重复元素，也不提供堆式poll()语义）
实际用的时候，最常被忽略的是：堆的“动态性”依赖于每次修改后内部结构的自动修复，而这个修复过程一旦被并发打断，就不可逆了。不是加个 synchronized 就万事大吉，得看操作是否构成一个完整的堆维护周期。
