priorityblockingqueue 不支持 null 元素，offer(null) 直接抛 nullpointerexception；按 double 权重降序需用 double.compare(task2.weight, task1.weight)；take() 线程安全但排序仅出队时生效，堆结构不保证数组有序；不可与 delayqueue 混用实现双维度排序。
PriorityBlockingQueue 的比较器必须支持 null 值吗？
不必须，但如果你往队列里 offer(null)，就会直接抛 NullPointerException——它本身不接受 null 元素。这点和 ArrayList 不同，也容易被误当成“能存空值的优先队列”。
常见错误现象：NullPointerException 出现在 offer() 或 put() 调用时，但堆栈没指向你自己的比较逻辑，让人误以为是并发问题。
- 所有元素插入前都会被检查是否为
null，这是硬性校验，绕不过 - 自定义比较器里如果用了
Objects.compare(a, b, cmp)之类工具方法，要确保传入的 a/b 本身非null - 若任务对象字段可能为
null（比如task.weight），比较器里得显式处理，例如：Integer.compare(Objects.requireNonNullElse(task1.weight, 0), Objects.requireNonNullElse(task2.weight, 0))
如何让 PriorityBlockingQueue 按 double 权重降序排列？
默认自然序是升序，权重越大越该先执行，就得手动反转。别直接用 Double::compareTo，否则小权重任务会挤到队首。
使用场景：任务带 score 或 priorityScore 字段，值越大越紧急，比如推荐系统里的实时打分任务。
实操建议：
- 写比较器时用
Double.compare(task2.weight, task1.weight)，注意参数顺序颠倒 - 避免用
(a, b) -> b.weight - a.weight，浮点减法可能产生NaN或精度丢失，Double.compare更安全 - 如果权重来自外部计算（如模型输出），建议在封装进任务对象前就做
Math.max(0, Math.min(Double.MAX_VALUE, weight))截断，防止 NaN 或无穷大破坏排序
PriorityBlockingQueue 的 take() 是线程安全的，但排序不是实时的
它的“优先级”只在出队（take() / poll()）那一刻生效，插入时不会重排整个队列。内部用的是最小堆，插入是 O(log n)，但堆结构不保证数组下标有序。
性能影响明显的情况：高频率插入 + 低频消费，比如每秒插入 1000 个任务、每 5 秒才 take() 一次。此时堆顶确实是最高优先级，但中间节点顺序不可预测，调试时打印 queue.toArray() 看到的不是按权重排好的列表，别慌——这是正常表现。
-
size()返回准确值，但遍历queue.iterator()不保证按优先级顺序 - 不要依赖
queue.toArray()[0]获取“当前最高优先级”，它可能不是真正的堆顶；要用peek() - 如果需要随时获取 top-K，别自己遍历，考虑用
PriorityQueue+ 外部锁，或换用ConcurrentSkipListSet（需自行处理并发更新）
和 DelayQueue 混用时，权重和延迟时间谁优先？
不能混用。PriorityBlockingQueue 不实现 Delayed 接口，也不感知时间。如果你需要“既按权重又等延迟”，得自己封装逻辑，比如把延迟时间转成一个参与排序的字段（如 effectivePriority = weight - (scheduledTime - System.nanoTime()) * decayRate）。
容易踩的坑：
- 误以为继承
Delayed就能让PriorityBlockingQueue自动按到期时间排序——它只看你提供的Comparator - 在
Delayed实现里重写getDelay()，但没同步更新用于排序的权重字段，导致任务“到了时间却迟迟不被取走” - 想用
DelayQueue+ 自定义compareTo()实现权重，结果发现DelayQueue强制要求Comparable且只按getDelay()排序，权重逻辑会被忽略
真正要兼顾两者，得放弃开箱即用的容器，老老实实自己维护一个 ConcurrentHashMap 存任务，再配一个定时调度器 + 优先级消费线程。
