PriorityBlockingQueue 插入不重排、出队才堆调整，遍历无序；无界队列，initialCapacity 仅为初始容量；Comparator 类型错配易致 ClassCastException；仅 take() 阻塞，offer()/put() 均不阻塞；线程安全，不可用 Collections.synchronizedQueue 包装 PriorityQueue。
PriorityBlockingQueue 的基本用法和构造陷阱
它不是按你传入的 Comparable 自动排序就完事的——队列内部只在出队（poll()、take()）或迭代时才做堆调整，插入（offer()、put()）本身不触发重排。这意味着：如果你用 toArray() 或直接遍历 iterator()，看到的顺序大概率不是优先级顺序。
- 必须用
poll()或take()才能按优先级取元素；peek()只返回队首（最高优先级），但不移除 - 构造时传
Comparator比依赖元素自身Comparable更可控，尤其当元素类型不可修改时 - 别用
new PriorityBlockingQueue(initialCapacity)以为能限制大小——它是无界的，initialCapacity只是初始堆数组容量，满后自动扩容
自定义 Comparator 导致的 ClassCastException 怎么查
错误常出现在泛型擦除 + 类型不匹配时，比如队列声明为 PriorityBlockingQueue<string></string>，但实际塞了 Integer，或者 Comparator 里写了 (a, b) -> a.intValue() - b.intValue() 却传入 String。
- 检查
Comparator中的强制类型转换，确保和实际入队对象类型一致 - 如果用 Lambda 写比较器，把参数显式声明为具体类型，比如
(String a, String b) -> a.length() - b.length()，避免泛型推导误判 -
ClassCastException堆栈通常指向heapify()或siftDownComparable()，说明问题发生在某次出队引发的堆调整中，而非插入当时
多线程下 offer() 和 take() 的阻塞行为差异
PriorityBlockingQueue 是“阻塞队列”，但它的“阻塞”只体现在消费者端：take() 在空时会阻塞，而 offer() 永远不会阻塞（因为无界）。这点和 ArrayBlockingQueue 或 LinkedBlockingQueue 不同。
-
offer(E e)总是立即返回true，哪怕内存快耗尽——它不检查资源，只管往堆里加 -
put(E e)虽然签名像阻塞方法，但实际也是立即返回，文档明确写 “never blocks” - 真正会阻塞的只有
take()和带超时的poll(long, TimeUnit)；peek()和size()也不阻塞 - 注意：高并发下频繁
offer()可能导致堆无限增长，OOM 风险比有界队列更高
和 PriorityQueue 的主要区别在哪（别混用）
两者都基于堆，但 PriorityBlockingQueue 是线程安全的，PriorityQueue 完全不是。直接把 PriorityQueue 包进 Collections.synchronizedQueue() 也不行——同步只包住了单个操作，堆结构在多线程修改下仍会不一致。
立即学习“Java免费学习笔记（深入）”；
-
PriorityBlockingQueue内部用ReentrantLock+ 条件队列实现线程安全，所有 public 方法都是原子的 -
PriorityQueue的iterator()是弱一致性快照，而PriorityBlockingQueue.iterator()返回的是强一致视图（但依然不保证顺序） - 不要试图用
synchronized(queue)包裹PriorityBlockingQueue——锁是多余的，还可能引发死锁
优先级队列的排序逻辑只在消费侧生效，且无界特性意味着你要自己盯紧内存水位；Comparator 类型错配和线程模型误用，是线上最常导致静默失败或 OOM 的两个点。
