大概很多年前我第一次做任务调度模块时，把所有待处理任务都塞进了一个普通队列，先进先出，看起来毫无问题。直到系统里突然混进来一个必须在几秒内给出结果的紧急请求，而它前面还堵着几百个耗时任务，那一刻我才真正意识到：并不是所有场景都适合“先来后到”。后来我把队列换成了 PriorityQueue，紧急任务可以插队到最前面，延迟暴跌，代码逻辑也清爽了很多。

PriorityQueue 的价值，说白了就是一句话：用 O(1) 时间看到全局最紧急的元素，用 O(log n) 时间插入或移除一个元素。它底层是一棵二叉堆，不是完整排序后的有序数组，也不会保证队列里所有元素按大小排成一条直线。这篇文章我把 PriorityQueue 的真实使用场景一次性捋清楚：任务调度、Top K 筛选、图算法、多路归并，以及那些我在实战中被坑过的细节。不论你是刚学数据结构的初学者，还是已经在业务系统里写过调度代码的开发者，这篇文章都值得留下来当参考。

1. 什么是 PriorityQueue：一个会按“紧急程度”插队的队列

1.1 从结构上先搞懂二叉堆

PriorityQueue 中文常叫“优先队列”，它首先是个队列，但出队顺序不由“谁先进来”决定，而由“谁的优先级高”决定。你可以把它想象成医院的急诊分诊台：普通门诊按挂号顺序叫号，但急诊患者来了可以直接往前排。

这里的底层结构通常是二叉堆（Binary Heap），更准确地说是最小堆。所谓最小堆，是指每个父节点的值都小于等于它的两个子节点。注意，这只约束了“父子之间”的关系，并没有约束“兄弟之间”的顺序。比如根节点是 3，它的两个子节点可以是 5 和 8，也可以左边是 8、右边是 5，这两种排列对于堆来说都是合法的。

正因如此，堆里的元素并不是全局有序的，它只是维持了一个“偏序”。你只能高效地拿到堆顶的最小元素，想要按从小到大的顺序遍历所有元素，反而做不好——这一点和很多人直觉里“优先队列就是自动排序的数组”完全不一样。

实现上，二叉堆通常用数组来承载。假设数组下标从 0 开始，那么下标 i 的元素的左孩子是 2 * i + 1，右孩子是 2 * i + 2，父节点是 (i - 1) / 2。这样做的好处是：不需要像二叉树那样存储左右指针，内存更紧凑，对 CPU 缓存也更友好。

插入元素时，先把元素放到数组尾部，然后不断和父节点比较，如果比父节点小就交换位置，这个过程叫上浮（sift up / bubble up）。由于堆的高度是 log n，所以插入操作的时间复杂度是 O(log n)。

取出最小元素时，做法是把数组最后一个元素挪到堆顶，然后不断和两个孩子中较小的那个比较，如果比孩子大就交换，这个过程叫下沉（sift down）。同样，时间复杂度是 O(log n)。至于“看一眼最小元素”，直接返回根节点，也就是数组下标 0 的位置，复杂度是 O(1)。

下面这段 Java 风格的代码展示了一个最小堆的插入和弹出流程，便于你对照理解：

PriorityQueue<Integer> pq = new PriorityQueue<>(); pq.offer(10); pq.offer(3); pq.offer(8); pq.offer(5); // 此时堆内逻辑结构大致为： // 3 // / \ // 5 8 // / // 10 // 但数组里实际存储的顺序可能是 [3, 5, 8, 10]，也可能是别的符合堆性质的排列 int min = pq.peek(); // 3，看一眼最小元素 int removed = pq.poll(); // 3，弹出最小元素

1.2 为什么不用有序数组、普通队列或者二叉搜索树

很多人会问：既然要取最小值，为什么不直接用有序数组？取最小值是 O(1)，不也挺好？问题的关键在于“动态插入”。

有序数组在插入时会面临大量元素搬移。想象一下你维护着一个容量很大的有序数组，往中间插入一个元素，后面所有元素都得往后挪一位，平均时间复杂度 O(n)。如果业务里不停地有新任务进来，这个 O(n) 的开销会极其心疼。

普通队列反过来，插入很方便，O(1)，但是每次找最小元素就要遍历一遍，代价 O(n)。如果任务量是百万级别，每取一个最小任务就得扫百万个元素，性能直接爆炸。

二叉搜索树（比如 TreeMap）也能做到 O(log n) 插入和取最小，看上去也不差。但二叉搜索树为了保证平衡，通常需要复杂的旋转操作，常数因子比堆大得多，而且每个节点要存储左右孩子、颜色标记等额外信息，内存占用也更高。二叉堆只要求“父节点小于等于子节点”，这个条件比二叉搜索树弱得多，所以维护成本天然更低。

堆真正擅长的场景是：只需要频繁取得“最大或最小的那一个”，而不需要支持搜索、删除任意元素、遍历排序等额外操作。很多人把 PriorityQueue 当全能排序工具用，这是最大的误解来源。

1.3 不同语言里的 PriorityQueue 实现

Java 标准库里的 PriorityQueue 默认是最小堆，如果想实现最大堆，要么传入 Collections.reverseOrder()，要么自定义 Comparator。C++ 的 priority_queue 则相反，默认是最大堆。Python 的 heapq 模块没有包装成类，而是直接提供一堆操作数组的函数，默认也是最小堆。三者的底层思路完全一致，换语言时只需要注意比较方向的差异。

我见过不少人在 Java 里想实现“最大的先出”，直接 new PriorityQueue<>() 然后以为重写 compare 就够了，结果写反了，排出来却是最小的先出。这一点在后面的实战细节里我会专门强调。

2. 任务调度场景：线程池、延迟队列和现实中的“插队需求”

2.1 普通队列在高并发任务下的崩溃现场

先说一个我实际遇到的场景。当时某内部服务要处理一批批外部回调数据，不同类型的回调有不同的时效要求：有的是普通数据同步，晚几分钟无所谓；有的是用户主动触发的操作结果，需要尽快返回。最开始实现非常简单，所有回调按到达顺序塞进一个普通队列，消费者线程从队列头部取任务。

高峰期问题就来了：某个用户触发了一个敏感操作，回调结果在队列尾部排队，可前面堆了成千上万个普通同步任务，每个任务还要做网络请求，平均耗时几十毫秒。结果那个紧急回调节点活活等了十几分钟，用户那边早就把页面刷新了好几遍，体验非常糟糕。

后来我把队列换成了 PriorityQueue，每个任务带一个优先级编号，紧急任务标记为 0，普通任务标记为 5，低优先级跑批任务标记为 10。消费者取数时永远拿堆顶的任务，紧急任务一旦进队，马上就能被处理。这个改动很小，但高峰时段紧急任务的响应时间从十几分钟降到了秒级。

2.2 把 PriorityQueue 接入线程池：包装任务类是核心写法

Java 里的 ThreadPoolExecutor 允许我们传入自定义的 BlockingQueue 作为任务队列。默认的 Executors.newFixedThreadPool 用的是 LinkedBlockingQueue，也就是普通的有界或无界队列，任务进去之后严格按提交顺序执行。

要让线程池支持优先级调度，可以把优先队列作为工作队列传入。但这里有一个很隐蔽的坑：提交给线程池的任务类型是 Runnable，你没法直接给 Runnable 排序。通常做法是自定义一个实现 Comparable 的任务包装类，把优先级字段放进比较器里。

class PriorityTask implements Runnable, Comparable<PriorityTask> { private final int priority; private final Runnable task; PriorityTask(int priority, Runnable task) { this.priority = priority; this.task = task; } @Override public void run() { task.run(); } @Override public int compareTo(PriorityTask other) { // 数值小的优先级高，所以返回负数表示当前任务优先 return Integer.compare(this.priority, other.priority); } }

然后创建线程池时传入 PriorityBlockingQueue：

ThreadPoolExecutor executor = new ThreadPoolExecutor( 4, 4, 60, TimeUnit.SECONDS, new PriorityBlockingQueue<>() ); executor.execute(new PriorityTask(5, () -> System.out.println("普通任务"))); executor.execute(new PriorityTask(0, () -> System.out.println("紧急任务")));

这里要注意，PriorityBlockingQueue 是无界队列，意味着队列永远不会满。如果你初始化线程池时设了 maximumPoolSize 大于 corePoolSize，那只要队列没满，线程池就只会创建 corePoolSize 个线程，多余的核心线程永远不会因为队列满而扩容。很多人用 PriorityBlockingQueue 时没意识到这一点，导致业务高峰期明明线程池配置了不少线程，实际却只有固定数量在跑。

2.3 DelayQueue 的内部实现就是 PriorityQueue

定时调度是另一个高频使用场景。倒排任务、会话超时检测、Redis 延迟队列的本地简化版，都能用 DelayQueue 实现。很多人不知道，DelayQueue 内部实际上就是用一个 PriorityQueue 来保存元素，比较依据是“剩余延迟时间”，剩余时间最短的元素排在堆顶。

它的核心逻辑很巧妙：消费者线程调用 take() 时，先查看堆顶元素，如果它的剩余延迟时间小于等于 0，就直接弹出执行；否则计算还需要等待多久，然后挂起等待。这样一来，线程不会像傻瓜轮询那样每隔一秒把所有任务扫一遍，而是精确地睡到下一个任务该被执行的时间点。

public class DelayTask implements Delayed { private final long executeTime; private final Runnable task; public DelayTask(long delayMillis, Runnable task) { this.executeTime = System.currentTimeMillis() + delayMillis; this.task = task; } @Override public long getDelay(TimeUnit unit) { return unit.convert(executeTime - System.currentTimeMillis(), TimeUnit.MILLISECONDS); } @Override public int compareTo(Delayed other) { return Long.compare(this.executeTime, ((DelayTask) other).executeTime); } }

使用起来很简单：

DelayQueue<DelayTask> queue = new DelayQueue<>(); queue.offer(new DelayTask(3000, () -> System.out.println("3 秒后执行"))); queue.offer(new DelayTask(1000, () -> System.out.println("1 秒后执行"))); while (true) { DelayTask task = queue.take(); // 会阻塞到最早任务的到期时间 task.getTask().run(); }

这段代码最丝滑的地方在于，DelayQueue 内部堆的比较器直接比较 executeTime，所以只要堆顶任务还没到期，其他任务就不需要关心；堆顶到期后，下一个到期任务又自动浮到顶部。整个过程不需要扫描全队列，在大规模定时任务场景下特别有用。

2.4 优先级调度里的“饥饿问题”值得警惕

使用优先级队列做任务调度之后，可能会遇到一个新的问题：如果系统不断有高优先级任务进来，低优先级任务可能会被无限期压着出不了头。比如你持续有 0 级任务进来，堆顶永远是它们，5 级、10 级任务就只能一直排在后面，直到高峰期过去。

这种情况在业务里很现实，所以设计优先级时脑子里要有“分级分池”的概念。一种常见做法是把系统拆成多个独立队列：紧急任务专用一个线程池，普通任务和跑批任务各自单独队列。紧急队列再满也不可能阻塞普通任务，普通任务再慢也不会被紧急任务完全饿死。另一种做法是给优先级动态老化：任务在队列里等待时间越长，计算优先级时加上一个等待补偿值。你不需要把这种策略一次性做得很完美，至少要意识到纯粹堆优先级的系统是有这个致命弱点的。

3. Top K 场景：在海量数据里选出“最值的那几个”

3.1 为什么求 Top K 要用小根堆而不是排序

Top K 问题是面试和实战里的常客：给你几亿条日志，要找出访问次数最多的前 100 个 IP；或者给一个商品点击流，要实时维护点击量最高的前 10 个商品。

最直接的做法是把数据全部加载进内存，全排序，然后取前 K 个。可是当数据量达到几亿条时，排序耗时 O(n log n) 不说，内存也被白白吃了大量空间。而且如果数据是源源不断产生的流，你不可能等所有数据到齐再排序。

PriorityQueue 提供了一种流式友好的解法：要求“最大的 Top K”，就用一个容量只有 K 的小根堆。为什么是“小根堆”？因为小根堆的堆顶是堆里最小的元素，也就是当前 Top K 的门槛。新元素来了，如果它比堆顶还小，那它连门槛都没进，直接丢掉；如果它比堆顶大，就把堆顶弹出，把它放进去。这样堆里始终保存着目前见过的最大的 K 个元素。

整个过程，每个元素只需要 O(log K) 时间的堆调整，总体复杂度 O(n log K)，内存占用只有 O(K)。如果 K 是 100，而数据量是几亿，这差距就是天壤之别。

3.2 一个标准的 Top K 实现代码

PriorityQueue<Integer> heap = new PriorityQueue<>(K); for (int value : dataStream) { if (heap.size() < K) { heap.offer(value); } else if (value > heap.peek()) { heap.poll(); heap.offer(value); } } // 堆中剩下的就是最大的 K 个数

我特别叮嘱一句：这个堆的堆顶，正好是第 K 大的数，而不是最大的数。你要找的最大值有时候得先 poll 掉很多元素才能看到，或者你可以另行保存一个 max 变量。很多刚接触的人会误以为“堆顶就是 Top 1”，然后越查越迷糊。

3.3 双堆配合：流式中位数的维护

Top K 的变体之一，是用两个堆来维护一个不断变化的数据流的中位数。一个最大堆保存较小的一半，一个最小堆保存较大的一半，两个堆大小相差不超过 1，中位数就是两个堆顶之一或是它们的平均数。

PriorityQueue<Integer> maxHeap = new PriorityQueue<>(Collections.reverseOrder()); // 较小的一半 PriorityQueue<Integer> minHeap = new PriorityQueue<>(); // 较大的一半 public void addNum(int num) { // 先放入最大堆，再把最大堆的堆顶弹出放入最小堆 maxHeap.offer(num); minHeap.offer(maxHeap.poll()); // 维持平衡 if (maxHeap.size() < minHeap.size()) { maxHeap.offer(minHeap.poll()); } } public double findMedian() { if (maxHeap.size() > minHeap.size()) { return maxHeap.peek(); } return (maxHeap.peek() + minHeap.peek()) / 2.0; }

这个场景出现在实时数据监控里特别多。比如某个服务在统计 P99 延迟，你不需要把所有采样点排序，只需要维护两个堆，每来一个请求耗时数据就更新一次，随时能给出当前窗口的中位数甚至分位数。我对这个写法的评价是：几乎所有“动态排序”场景，都能用“堆”来降维打击。

3.4 但 Top K 不是万能的：数据分布剧烈变化时的应对

这里必须泼一盆冷水：如果你要维护的 Top K 面临大量数据进出，比如每分钟都有几十万条更新，全部交给一个堆处理，堆调整的次数会非常多。实际生产里常会用“两层漏斗”：先经过一个抽样或者粗过滤，只把有希望进入前 K 的数据送到精细堆里。比如先判断元素是否大于堆顶的十分之一，低于阈值直接丢弃，只有超过阈值才做堆操作。这个优化虽然不能严格保证 Top K 绝对正确，但能在绝大多数业务场景里把计算量砍掉一大截，属于典型的“工程正确”思维。

4. 图算法：PriorityQueue 是 Dijkstra 最短路径的发动机

4.1 Dijkstra 朴素实现的瓶颈在哪里

图论里最经典的算法之一就是 Dijkstra 最短路径。它的核心逻辑是每次从“还没确定最短距离”的节点中，选一个当前距离最小的人，用它去松弛邻居。

朴素实现里，这个“选一个当前距离最小的节点”的操作，需要遍历所有未确认节点，复杂度 O(V)。整个算法外层要循环 V 次，于是总复杂度 O(V²)。在稠密图，比如几百个节点全连接的场景，O(V²) 不算糟；但在稀疏图，比如几万个节点、每个节点只有几条边，O(V²) 就是不可接受的浪费。

PriorityQueue 的作用，就是把这个“选最小”的操作从 O(V) 降到 O(log V)。每次松弛一个邻居之后，把新的距离和节点打包扔进堆里。堆顶就是当前距离最小的那个节点。整体复杂度优化到 O((V + E) log V)。节点越多、边越少，这个优化越明显。

4.2 用 PriorityQueue 重写 Dijkstra 以及“延迟删除”

下面是一份极简但可运行的 Dijkstra 实现思路，用 PriorityQueue 保存每个节点当前已知的最短距离。请注意，这里有个常见的重复入堆问题：某个节点可能被多条路径先后更新，堆里会同时存在新距离和旧距离。

class State { int node; int dist; State(int node, int dist) { this.node = node; this.dist = dist; } } Map<Integer, Integer> dist = new HashMap<>(); PriorityQueue<State> pq = new PriorityQueue<>(Comparator.comparingInt(s -> s.dist)); dist.put(start, 0); pq.offer(new State(start, 0)); while (!pq.isEmpty()) { State cur = pq.poll(); if (cur.dist > dist.getOrDefault(cur.node, Integer.MAX_VALUE)) { continue; // 老旧的过期记录，直接跳过 } for (Edge edge : graph.get(cur.node)) { int nextDist = cur.dist + edge.weight; if (nextDist < dist.getOrDefault(edge.to, Integer.MAX_VALUE)) { dist.put(edge.to, nextDist); pq.offer(new State(edge.to, nextDist)); } } }

那个 continue 的检查，就是所谓的“延迟删除”：堆里留着的旧记录并不主动移除，而是等它被弹出时判断一下，如果它已经不再是最新距离，就忽略。这个技巧让代码不必实现复杂的“任意元素删除”，大大简化了堆的使用方式。

4.3 Prim 最小生成树是同一套套路

很多人只知道 Dijkstra，不知道 Prim 最小生成树算法也依赖同样的思想。Prim 每次从未在生成树中的节点里，选择一个“与当前生成树连接边权值最小”的点加入树。这个“最小值”同样可以用 PriorityQueue 维护。

Dijkstra 的“距离”是从起点到当前节点的累加距离，Prim 的“距离”是当前节点到已构建生成树的最小边权。两者一个针对最短路径，一个针对最小生成树，但引擎部分都是同一套：一个最小堆在选择全局最小点上提供高效支撑。

4.4 Dijkstra 的一个硬性前提

我在这里必须强调，Dijkstra 不允许有负权边。假设有一条边的权重为负数，贪心地认为“当前距离最小以后不可能再被更新”就会失效，因为后面可能出现一条更长的路径，绕了一圈经过负权边，反而总距离变小了。遇到负权图，该用 Bellman-Ford 或 SPFA 就换算法，别硬拿 PriorityQueue 硬扛。曾有次我在一个成本计算系统里，把“退款订单”的权重配成了负数，结果运行结果稳定输出错误，排了半小时才发现是 Dijikstra 的负数问题。

5. 多路归并：把 K 个有序序列高效合并成一个

5.1 K 个有序序列合并的直觉做法为什么慢

现实中会经常遇到“合并多个有序序列”的问题。比如系统一天产生几十个日志文件，每个日志文件内部按时间有序；现在要合并成一个全局按时间有序的大文件。又比如数据库某个索引分区有 K 个有序子段，需要做一个归并排序。

最直觉的写法是：每次从 K 个序列的当前头部元素里，找一个最小的拿出来，放到结果里。如果每个序列元素数量十分庞大，总共 N 个元素，每次找最小值都要扫一遍 K 个头，总复杂度 O(K * N)。K 是 10 的时候还能接受，K 是 1000 的时候就灾难了。

5.2 用最小堆实现 O(N log K) 的多路归并

PriorityQueue 的正确用法是：先把 K 个序列各自的第一个元素放入小根堆。然后每次从堆顶弹出最小值，放入结果，再从弹出元素所属的那个序列里补齐下一个元素。这样每个元素都经历一次入堆和一次出堆，复杂度 O(N log K)，而且堆的大小始终只有 K，内存占用极小。

class QueueNode { int value; int listIndex; int elementIndex; QueueNode(int value, int listIndex, int elementIndex) { this.value = value; this.listIndex = listIndex; this.elementIndex = elementIndex; } } public List<Integer> mergeKSortedLists(int[][] lists) { PriorityQueue<QueueNode> pq = new PriorityQueue<>(Comparator.comparingInt(node -> node.value)); for (int i = 0; i < lists.length; i++) { if (lists[i].length > 0) { pq.offer(new QueueNode(lists[i][0], i, 0)); } } List<Integer> result = new ArrayList<>(); while (!pq.isEmpty()) { QueueNode cur = pq.poll(); result.add(cur.value); int nextIndex = cur.elementIndex + 1; if (nextIndex < lists[cur.listIndex].length) { pq.offer(new QueueNode(lists[cur.listIndex][nextIndex], cur.listIndex, nextIndex)); } } return result; }

每个序列的第一个元素先进堆，弹出之后，再从同一个序列里补下一个。因为每个序列本身已经有序，所以补充进来的元素永远是自己序列里当前最小的那个，放进堆里和其他序列继续比较不会错。

5.3 从多路归并到外部排序

多路归并可不仅仅是算法题。外部排序的经典流程是：当数据量超过内存时，先把大文件切成一份份能在内存里排好序的小块，再把所有小块用上面这个“最小堆多路归并”的方式合并成一个整体。K-way merge 就是 PriorityQueue 在文件系统级排序里的落地场景。

另外，有些数据库执行引擎在做排序算子时，也会把多个有序输入流用堆来统一拉链合并，避免 O(K * N)。如果你以后听到某个系统说“用外部排序合并结果集”，它内部大概率就藏着一个 PriorityQueue。

6. 使用 PriorityQueue 时最容易被坑的细节

6.1 迭代器不保证有序，遍历结果可能“看似乱序”

有一个误解几乎每个入门者都会踩：往 PriorityQueue 里添加几个元素之后，有人会用 for (int x : pq) 遍历一遍，发现输出顺序和想象中的排序完全不同，于是怀疑堆坏了。

堆的结构决定了数组里存储的顺序只满足父子之间的偏序关系，数组下标相邻的元素之间没有任何顺序保证。如果你必须按优先级依次处理所有元素，正确做法是循环 poll：

while (!pq.isEmpty()) { // 堆顶永远是最小值 doSomething(pq.poll()); }

不要贪图 for-each 的便利，否则拿到的顺序不保证，调试时极易自我怀疑。

6.2 比较器方向写反、相等元素顺序不稳定

Java 的 PriorityQueue 默认是最小堆，也就是数值小的先出队。如果你想要数值大的先出队，需要传入一个反序比较器，比如：

PriorityQueue<Integer> maxHeap = new PriorityQueue<>(Comparator.reverseOrder());

这里最坑的是 compare 方法里的返回值。如果你写的是return a - b，两个数相差很大时可能因为整型溢出出现问题；更稳妥的写法是Integer.compare(a, b)。我见过有人写return b - a本意是做最大堆，结果因为后续代码里又包装了一层，方向再次取反，最后查了很久才发现优先级反了。

对于相等元素，PriorityQueue 不保证它们的排列顺序。如果业务上要求优先级相同的任务按插入顺序执行，传统 PriorityQueue 是做不到的，你得给每个元素额外加一个自增序号做第二排序键。

6.3 对象入堆之后就不要再修改排序字段

这一点是我自己踩过的最大一次坑。Java 的 PriorityQueue 不会在元素入堆之后再检查你手动修改的字段是否影响堆序。如果对象入堆后，你改了它的 priority 字段，堆可能已经不再满足“父节点小于等于子节点”的性质，后续 pop 出来的就不是真正的最小值。

举个例子，做 Dijkstra 时如果你没有使用“延迟删除”，而是直接修改 State 对象的 dist 字段，堆会立刻失效。我曾在项目里引入一个组件对象池，对象被复用前要重置 priority，结果对象已经躺在堆里，重置之后堆整个乱了，排查了很久才发现这个原理性错误。

正确做法是：需要变更时，把元素先 poll 出来，或者新建一个对象再 offer 进去，千万不要原地改对象里参与排序的字段。

6.4 无界队列与线程池的一个隐藏联动

前文已经提到，PriorityBlockingQueue 是无界的，用它做线程池工作队列时，即使线程池的 maxPoolSize 大于 corePoolSize，队列也永远不会满，所以额外的线程永远不会有被创建的机会。这类无界队列还有一个风险：如果生产者速度长期高于消费者速度，队列里的任务会无限积压，最终造成内存溢出，而且由于没有边界，拒绝策略也永远不会触发。

如果系统对任务积压量有容忍上限，一个更合理的设计是用有界队列，或者干脆用独立的线程池隔离不同优先级。很多上线事故，表面是内存被吃满，本质是“无界队列 + 优先级任务无限堆积”两头同时发威。

6.5 K 非常小时，别迷信 PriorityQueue

最后说一个我现在的习惯：如果 K 很小，比如只要 Top 3，或者只需要从 5 个元素里挑最小，PriorityQueue 的开销不一定比线性扫描小。PriorityQueue 每次调整堆结构都有常数因子，插入元素还要创建新对象，这些都有成本。在这种小规模场景下，一个 for 循环穷举找出最小值，可能比堆更快、更直观。

我通常给自己定一个粗略经验线：K 大于 20 才认真考虑用堆；否则直接线性扫描。当然这不是铁律，和具体语言的堆实现效率、对象分配成本都有关系。但不要因为“用堆看起来很高级”就处处堆化，性能优化应该建立在实测基础上，而不是数据结构的刻板印象上。

写到这里，PriorityQueue 的核心应用场景和坑基本都过了一遍。我自己的实际体会是：每次使用之前先问自己三个问题——我是否只需要最值而不需要全局有序？我需要频繁插入和删除吗？会不会有并发访问？如果三个问题的答案分别是“是、是、否”，那 PriorityQueue 几乎就是你最合适的选择。如果还有并发访问，比如在同一个线程池或消息队列里使用，记得换成线程安全的 PriorityBlockingQueue，不要在不设防的情况下让多个线程去写同一个 PriorityQueue。最后再提醒一句，对象入了堆就别再改它的比较字段，这是它最容易“悄悄变坏”的死穴。