应使用小顶堆而非大顶堆找前K个最大元素，因为小顶堆堆顶为当前K个数中最小者，可高效淘汰较小候选者；大顶堆堆顶为最大值，无法准确维护前K大集合。
用大顶堆找前 K 个最大元素是反直觉的——实际应使用小顶堆。大顶堆适合找前 K 个最小元素，而海量数据中求前 K 大，标准解法是维护一个容量为 K 的小顶堆。
为什么不用大顶堆？
大顶堆的堆顶是最大值。若用它存前 K 个最大数，每次新元素进来都要和堆顶比：如果新数比堆顶还大，说明堆顶已不是“前 K 大”里的成员，但此时无法直接替换堆顶，因为堆顶被挤掉后，剩下 K−1 个数里可能有比新数更小的，逻辑混乱。更关键的是，大顶堆无法高效淘汰“当前最小的候选者”，而这正是小顶堆的天然优势。
正确做法：用小顶堆维护 K 个最大数
小顶堆的堆顶是这 K 个数中最小的那个。当新元素大于堆顶，说明它更有资格进入前 K 名，直接替换堆顶并下沉调整；否则跳过。这样堆里始终保存着当前见过的最大的 K 个数，且堆顶是其中最小者，充当“门槛”。
- 初始化一个大小为 K 的小顶堆（如 Java 的 PriorityQueue<Integer>，构造时传 Comparator.reverseOrder() 是错的——那是大顶堆；小顶堆用默认构造即可）
- 遍历数据流：对每个元素，若堆未满，直接加入；若已满，且当前元素 > 堆顶，则 poll() 掉堆顶，再 offer() 当前元素
- 遍历结束后，堆中 K 个元素就是前 K 大，顺序不保证，可转数组后排序或直接遍历输出
处理海量数据的关键细节
数据量远超内存时，不能一次性加载。需结合外部排序或分块处理：
立即学习“Java免费学习笔记（深入）”；
- 将数据分片读入内存，每片用小顶堆求出该片的前 K 大，合并成最多 K×片数 个候选数
- 对所有候选数再跑一次小顶堆（大小仍为 K），得到全局前 K 大
- 若用 MapReduce 或 Spark，可 map 阶段每台机器算局部前 K，reduce 阶段汇总后取全局前 K
Java 实现示例（核心逻辑）
// 注意：这是标准小顶堆写法，不是大顶堆
PriorityQueue<Integer> minHeap = new PriorityQueue<>(K);
for (int num : nums) {
if (minHeap.size() < K) {
minHeap.offer(num);
} else if (num > minHeap.peek()) {
minHeap.poll();
minHeap.offer(num);
}
}
最终 minHeap 中即为前 K 大元素。
