PriorityBlockingQueue并发下优先级“不准”是因为其堆结构仅在take/poll时保证堆顶最高优先级，插入时不阻塞其他线程，中间态可能导致短暂顺序异常，且迭代器等不保证有序。
PriorityBlockingQueue 在并发环境下不保证实时优先级排序。它底层基于无界堆（heap），插入和删除操作满足堆性质，但其“优先级”仅在出队时体现，且多个线程同时操作时，优先级顺序可能被调度、CAS竞争或批量操作打乱，并非严格按优先级立即响应。
为什么并发下优先级看起来“不准”？
PriorityBlockingQueue 的 put/take 操作是线程安全的，但它的排序逻辑不锁整个队列——插入时只做上浮（sift-up），取出时只做下沉（sift-down），中间过程不阻塞其他线程的插入。这意味着：
- 多个线程连续 put 不同优先级元素时，堆结构可能尚未完全调整到位，后续 take 可能暂时拿到“非最高优先级”的元素（尤其在高并发短时密集写入场景）
- take 操作本身是原子的，但“谁先拿到锁、谁先完成下沉”受线程调度影响，不等价于“谁的元素优先级最高就一定最先被取走”
- 没有全局重排机制：队列不会在每次插入后重新堆化整个数组，只维护局部堆序，因此中间状态可能短暂违反全序预期
哪些操作真正触发优先级生效？
优先级只在以下两个动作中起决定性作用：
- take()：阻塞获取头元素，此时头一定是当前堆中优先级最高的（根据 Comparator 或自然序）
- poll()：非阻塞获取头元素，同样返回当前堆顶，即最高优先级项
而 peek()、iterator()、toArray() 等方法不保证返回有序结果——它们只是按底层 Object[] 数组顺序遍历，该数组是堆式存储（近似完全二叉树层级展开），并非升序/降序排列。
如何写出可预期的优先级行为？
若业务强依赖“高优先级任务一定更早执行”，不能只靠 PriorityBlockingQueue 单独使用，需配合外部控制：
- 避免多线程直接并发 put；改用单生产者线程收集任务，再批量或串行入队
- 在 take 后、执行前做二次校验（例如检查任务 deadline 或 priority 字段），必要时丢弃或重入队
- 对延迟敏感场景，考虑用 ScheduledThreadPoolExecutor + DelayedWorkQueue，它专为延迟+优先级设计，语义更明确
- 如需强一致性排序，可用 ReentrantLock + PriorityQueue 手动加锁封装，但会损失吞吐量
一个典型误用示例
有人这样测试：
queue.put(new Task(10)); // 优先级10（数字越小越高） queue.put(new Task(1)); System.out.println(queue.take().priority); // 期望输出1，实际可能输出10？
其实不会——只要 take 发生在两个 put 之后，结果一定是 1。但如果在第二个 put 尚未完成 sift-down 时就有另一个线程调用了 take（极小概率，但堆调整有中间态），则可能看到异常。不过 JDK 实现已确保每个 put/take 内部完成堆修复，所以单次 take 总是返回当前合法堆顶。真正的问题常出现在误解了“迭代器遍历”或“size() + peek() 推断顺序”这类非原子组合操作上。
