priorityblockingqueue 是无界阻塞队列，基于 reentrantlock 和 notempty 条件变量实现线程安全与阻塞语义；逻辑无界但受堆内存限制，扩容为1.5倍，持续写入可能引发 oom；仅消费端阻塞（如 take），生产端永不阻塞；禁止 null 元素，要求 comparator 稳定且元素可序列化。
PriorityBlockingQueue 是无界队列，本身不依赖锁来控制并发入队/出队，而是靠内部的可重入锁（ReentrantLock）+ 条件变量实现线程安全和阻塞语义。它没有容量限制，不会因“满”而阻塞入队；但出队操作（如 take()）在队列为空时会阻塞，直到有元素可用。
无界性与内存风险
PriorityBlockingQueue 底层用数组实现，默认初始容量为 11，扩容策略是：新容量 = 旧容量 + (旧容量 >> 1)（即约 1.5 倍）。虽然逻辑上“无界”，但实际受 JVM 堆内存限制。持续写入且消费过慢时，可能触发 OOM。
- 避免在高吞吐、低消费场景中直接使用默认配置
- 必要时通过构造函数指定较大初始容量，减少频繁扩容开销
- 配合监控（如队列 size()）或背压机制（如 tryOffer + 降级策略）防范内存失控
优先级与线程安全保证
元素按自然顺序或自定义 Comparator 排序，每次 poll/take 返回当前最小（或最大）元素。所有 public 方法（offer、poll、take、peek 等）都是线程安全的——内部统一使用同一把 ReentrantLock（notEmpty 条件队列用于等待非空，无 notFull 条件，因为不会满）。
- 插入和删除都加锁，不存在“部分排序可见”问题，多线程下堆结构始终一致
- 注意：迭代器（iterator()）不保证强一致性，遍历时队列可能被修改，返回结果可能是某一时刻的快照
- Comparator 若未处理 null 或比较异常，会在 offer 时抛出 RuntimeException，需提前校验
阻塞行为只发生在消费端
由于无界，offer 和 add 永远不会阻塞或返回 false；但 take() 会一直阻塞直到有元素，poll(long, TimeUnit) 可设超时。这种设计适合“生产快、消费稳”的典型异步任务调度场景。
- 慎用无超时的 take()，避免线程永久挂起（如上游停发、下游卡死）
- 若需控制等待时间，优先用 poll(timeout)，并检查返回值是否为 null
- 中断响应良好：take() 和带超时的 poll() 都能响应 Thread.interrupt()
不支持 null 元素与常见误用
PriorityBlockingQueue 明确禁止 null 元素，offer(null) 或 put(null) 会立即抛 NullPointerException。这点比 ArrayBlockingQueue 更严格（后者仅在 put 时拒绝 null）。
- 序列化/反序列化需确保元素类可序列化，否则 take 后反序列失败会导致队列状态异常
- 不要在 Comparator 中修改元素状态（如更新时间戳），会影响堆结构稳定性
- 避免在队列中存放可变对象且外部修改其参与排序的字段，否则 poll 结果可能不符合预期
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
