“堆”的终极辨析：从二叉堆、堆排序到内存堆与堆外内存

先给你交个底：如果你在搜索引擎里敲一个“堆”字，出来的结果会非常分裂。二叉堆、堆排序、优先队列、栈和堆、堆外内存、充电堆全矩阵……甚至还有一个叫“小土堆”的PyTorch教程博主。这个话题之所以让人头大，不是因为某个概念难，而是因为同一个汉字同时踩中了数据结构、运行时内存、硬件设计等多个没有交集的领域。

这篇文章想做的，就是把这些概念真正“一网打尽”。我会把工程和面试中最常遇见的二叉堆仔仔细底拆开，从结构原理到上浮下沉、建堆、堆排序，再到TopK、动态中位数、堆优化Dijkstra这些高频实战场景；然后再把大家最容易搞混的内存堆、栈、堆外内存这些概念单独拎出来说清楚，最后补上我在平时代码review和线上排障里见到的几个经典翻车案例。不管你是准备面试、刷算法题，还是工作中被OOM问题追着跑，这篇应该都能帮你省不少时间。

1. 先分清三种叫“堆”的东西，别让概念混战拖垮你

1.1 数据结构里的堆：二叉堆到底是什么

计算机科学里说的“堆结构”“二叉堆”，本质上是一种满足特殊顺序要求的完全二叉树。它有两个关键约束：

• 必须是一棵完全二叉树：除了最后一层，其他层必须从左到右饱满地填满，最后一层的节点也全部靠左排列。
• 必须满足堆序性质：任意父节点与子节点之间存在固定的大小关系。

如果父节点永远大于或等于子节点，它叫大根堆，也叫最大堆，堆顶就是全局最大值。如果父节点永远小于或等于子节点，它叫小根堆，也叫最小堆，堆顶就是全局最小值。

你只需要记住一个核心：堆是“偏序”的，只负责最快地给最值，不负责整体的有序。

1.2 内存管理里的堆：进程堆区不排队

程序运行时，操作系统会把进程内存划分成不同的区域。其中的“堆区”是动态分配内存的地方，用C语言里的malloc、C++里的new、Java里的new创建的对象或数组，往往都落在堆区。

内存堆和数据结构堆没有任何从属关系。内存堆的本质是一块可以按需申请、释放的运行时区域，并不需要时刻满足某个“父子比较规则”，也不会因为堆内存的地址长得像完全二叉树就真的有二叉树在里面。

1.3 充电堆、堆叠封装、小土堆的“堆”属于另一类

搜出来的“充电堆全矩阵与半矩阵方案”，是新能源充电基础设施里的群充设备方案，核心是把充电功率池化；HBM里的“DRAM堆叠层封装”，是先进封装工艺中把多层DRAM die垂直叠起来；“小土堆”只是博主ID里带个“堆”字，跟技术堆毫无关系。

之所以单独用一小节说这些，是因为很多人搜“堆”时，真正的目标其实分散在各处。先把语义对齐，后面才能聊得顺。

如果你要搜索资料，建议带上限定词：想了解数据结构就搜“二叉堆”或“heap data structure”；想了解JVM运行时分区就搜“JVM heap”；这样搜出来的结果才不会被跑偏。

2. 二叉堆的底层结构：为什么“完全二叉树+动态数组”是黄金组合

2.1 完全二叉树约束与下标公式

堆之所以可以用数组而不是真正的树节点，关键就在于“完全二叉树”这个约束。按层序遍历顺序把二叉堆节点放进数组，你会发现节点之间有空隙吗？完全没有：除了最后一层的右侧可能有缺口之外，整个数组是紧凑的。

这样一来，父子关系就能用下标公式直接算出。这里我用两种习惯分别列一下：

很多手写堆翻车，就是没搞清楚自己在用哪一种习惯。比如一套从1开始写的堆排序逻辑，硬套到Python列表（0-based索引）上，不到三步就会数组越界；反过来，把(i - 1) // 2硬套到1-based的代码里，根节点的父节点计算也会出问题。

我个人写算法题时，Python版本习惯统一用0-based，heapq本身也按这个约定走；如果是在笔试白板上手写堆排序，反而更偏爱1-based写法，因为公式天然对齐“左孩子是2i，右孩子是2i+1”，思路更不容易绕晕。

2.2 堆序性质与大/小根堆选择

堆的第二个约束是“堆序”，但它并没有限制兄弟节点的大小，也没有限制整棵树的有序性。拿小根堆来说，你只能保证根是最小的，但无法保证左子树里的所有节点一定小于右子树里的节点。反过来，左子树某个节点也可能大于右子树的节点，这并不违反堆的性质。

这种“只保父子、不保兄弟”的结构决定了堆的脾气：它擅长动态维护最值，但不擅长查找。你想在堆里查一个“大于某个值”的数，只能碰运气走偏路，最坏情况得遍历所有节点。

选择大根堆还是小根堆，完全取决于你希望O(1)时间拿到的是最大值还是最小值：

• 要最大值，用大根堆，根节点就是答案；
• 要最小值，用小根堆，根节点就是答案；
• 如果想同时维护最大值和最小值，那通常不是换一个堆，而是搭两个堆，后面第5章会细说。

2.3 堆不是有序表：那些常见的理解误区

我经常在面试里遇到候选人对堆有一些朴素的错误想象，这里一次性纠正掉。

误区一：把堆当成一个永远有序的数组。堆的数组布局只保证任意父节点和子节点之间满足比较关系，堆顶是最值，但堆的“第二个元素”（比如下标1或2）并不保证是整个集合的第二大或第二小。想取次大值，办法是先把堆顶拿出来，再让堆自我调整一次，然后新的堆顶才是次大值。

误区二：觉得堆能和二叉搜索树一样快速查找任意目标值。二叉搜索树的左小右大给查找提供了方向，堆没有这个全局信息，查找不是它的主场。堆的下沉、上浮等操作可以快速把最值顶上来，但你想定位的如果不是最值，那就得老老实实扫一遍。

误区三：以为二叉堆一定用链式二叉树来存。数组存储才是工程和算法题里的主流形态，不仅省去大量节点对象和指针开销，也能靠连续内存命中CPU缓存。你如果硬要拿TreeNode去写堆，往往写起来别扭，性能也远不如数组方案。

3. 手写二叉堆核心方法：上浮、下沉、建堆的全过程

不要只会调heapq或priority_queue，至少得能手写一个小根堆，因为堆排序、变种堆、批量堆化等场景都在这些基础动作上展开。核心方法其实只有三个：上浮、下沉、建堆。

3.1 上浮：插入元素如何找到“正确位置”

插入一个新元素时，最直接的方法是先把它追加到数组末尾。这个位置可能破坏堆序，比如小根堆中，如果新元素比父节点还小，父节点就“不配”当它父节点，于是需要让新元素沿着父链一路向上交换，直到到达一个不再违反堆序的位置。

Python版的小根堆插入可以这样写：

python复制class MinHeap:
    def __init__(self):
        self.heap = []

    def push(self, val):
        self.heap.append(val)
        self._sift_up(len(self.heap) - 1)

    def _sift_up(self, i):
        parent = (i - 1) // 2
        while i > 0 and self.heap[parent] > self.heap[i]:
            self.heap[parent], self.heap[i] = self.heap[i], self.heap[parent]
            i = parent
            parent = (i - 1) // 2

为什么上浮不会影响根节点以外区域的堆序？因为路径上每次交换都把更小的元素向上带，交换前子树本身已经满足堆序，被交换下来的较大节点依然大于或等于新的子节点，所以不会破坏子树全局。这就是堆调整里最重要的一点：一次局部交换只影响路径上的堆序，别的地方不用动。

上浮的代价与树高成正比。二分堆的树高是O(log n)，所以单次插入是O(log n)，最坏也不过是从叶子一路换到根。

3.2 下沉：删除堆顶后的重整流程

删除堆顶是另一个高频操作。先把数组最后一个元素临时搬到堆顶，数组长度减一，然后让这个新堆顶和它的孩子比较，不断选择符合条件的子节点交换下去。

小根堆里选哪个孩子交换是有讲究的：必须选两个孩子中更小的那个。为什么？因为如果选较大的那个交换，交换后它虽然比父节点大，但另一个没被选中的孩子可能比它更小或者两者相等，这样还是会被破坏“父节点不大于孩子”的规则。选较小的孩子，可以保证交换后父节点一定不大于两个孩子。

下沉代码：

python复制    def pop(self):
        if not self.heap:
            raise IndexError("pop from empty heap")
        root = self.heap[0]
        last = self.heap.pop()
        if self.heap:
            self.heap[0] = last
            self._sift_down(0)
        return root

    def _sift_down(self, i):
        n = len(self.heap)
        while True:
            smallest = i
            left = 2 * i + 1
            right = 2 * i + 2
            if left < n and self.heap[left] < self.heap[smallest]:
                smallest = left
            if right < n and self.heap[right] < self.heap[smallest]:
                smallest = right
            if smallest == i:
                break
            self.heap[smallest], self.heap[i] = self.heap[i], self.heap[smallest]
            i = smallest

这里有个细节，很多教学代码不会专门提醒：每次下沉交换后，要继续检查交换后的位置，而不是只做一次比较。因为一个元素可能一路从根沉到叶子。上面的while True就是持续检查直到不再需要下沉，这种写法比只下沉一次的递归版本更不容易出错。

3.3 建堆：逐个插入与自底向上调整，谁更快

给一个乱序数组，想把它变成堆，有两个常见办法：

方法A：从空堆开始，一个个调用插入。每个元素都要上浮，上浮代价在最坏情况下为O(log n)，因此总代价是O(n log n)。

方法B：先原样保留数组，然后从最后一个非叶子节点开始，从右往左、从下往上执行下沉。这个办法就是很多人常说的heapify，它的时间复杂度为什么是O(n)？

简单推导一下：假设堆有h层，越靠近叶子层的节点数量越多，但它们最多下沉的次数也越少。第k层每个节点最多下沉(h-k)次，而这一层有约2^k个节点，总工作量就是：

2^0 * h + 2^1 * (h-1) + ... + 2^(h-1) * 1

这个几何级数求和的结果是2n级别的，比线性的n略大但也属于O(n)。直觉理解就是，大多数节点都分布在靠近叶子的层数，它们的下沉路径极短；而只有最上面少数几个节点才有较长下沉路径，但它们的数量已经指数级减少了。

对应代码如下：

python复制def heapify(arr):
    n = len(arr)
    for i in range((n - 2) // 2, -1, -1):
        _sift_down_from_index(arr, i, n)

def _sift_down_from_index(arr, i, n):
    while True:
        smallest = i
        left = 2 * i + 1
        right = 2 * i + 2
        if left < n and arr[left] < arr[smallest]:
            smallest = left
        if right < n and arr[right] < arr[smallest]:
            smallest = right
        if smallest == i:
            break
        arr[smallest], arr[i] = arr[i], arr[smallest]
        i = smallest

最后一个非叶子节点在0-based数组中的下标是(n - 2) // 2，这一点很容易记错。以n = 5为例，最后一个元素下标是4，它的父节点是(4 - 1) // 2 = 1，即下标1才是最后一个可能“有孩子”的节点。堆化从1开始向上遍历就能覆盖整棵树，不需要遍历叶子。

3.4 语言层面的现成实现与自定义比较器技巧

你不需要每次都用tree或自己从零写堆。实际开发中，轮子都是现成的：

• Python：内置模块heapq，默认小根堆，底层就是一个普通list外加一堆函数。
• C++：std::priority_queue，默认大根堆，通过传入std::greater<int>可以切换为小根堆。
• Java：PriorityQueue类，默认小根堆，可以传入自定义Comparator做成大根堆。

Python里想要大根堆，最常见的技巧是把存入的值取负号，取出时再取负还原。比如要维护前K小元素时，你可以用堆存-x，让较大的负数在堆顶，进而实现“最大堆”的效果。

python复制import heapq
max_heap = []
heapq.heappush(max_heap, -10)
heapq.heappush(max_heap, -5)
top_value = -heapq.heappop(max_heap)  # 得到10

这么绕一圈，本质是因为Python的heapq没有直接提供max-heap接口，但这算是最轻量、最常见的工程解法。

4. 堆排序：流程、不稳定性和使用场景

4.1 排序流程：堆顶反复与末尾元素交换

堆排序的思路很直白，原地进行：

1. 把原数组调整成大根堆或小根堆。
2. 堆顶是当前最大值（以升序排序为例，用大根堆）。
3. 把堆顶和当前数组末尾元素交换，最大元素被放到最终位置上。
4. 将堆的有效长度减一，对新的堆顶做下沉，修复堆序。
5. 反复执行步骤3和4，直到堆里只剩一个元素。

看起来每次取堆顶O(log n)，一共n次，所以总复杂度是O(n log n)。空间复杂度O(1)，因为全程在原数组上交换。

C++或伪代码并不复杂，核心就是“建堆+反复pop到尾部”。很多人喜欢对比快排和堆排序：同样是O(n log n)级别的时间复杂度，为什么实际排序库很少用堆排序？因为堆排序的交换次数和常数通常比优化后的快速排序大，而且数组访问模式在缓存上不如快速排序友好——堆排序会频繁跳跃访问数组中的不相邻位置。不过堆排序也有它独特的好处：不需要额外递归栈空间，也没有快排那种最坏情况下退化到O(n^2)的问题。

4.2 为什么堆排序不稳定

排序算法的稳定性是指：两个相等的元素，在排序后能不能保持原有的相对顺序。堆排序是不稳定的。

举个例子，假设大根堆里有值相等的元素A和B，A原本在下标2，B原本在下标5。堆调整过程中，B可能先被交换到堆顶，又被交换到数组末尾，越过A的位置，最终变成A在后、B在前。相等元素之间的相对位置没法保证，于是它就不稳定。

4.3 什么情况下我会主动选堆排序

虽然业务排序一般用sort()，但下面两类场景我会认真考虑堆排序：

• 对内存要求极苛刻的嵌入式或底层环境，且需要原地、复杂度有上界保证的排序；
• 面试或竞赛题里明确要求O(1)额外空间并且不接受最坏退化，快排不是那么保险时，堆排序反而是最稳的选择。

顺手列一个简单对照表：

5. 堆的高频应用：从TopK到动态中位数再到图算法

5.1 优先队列：堆最常见的工程外衣

优先队列和堆的关系非常近。你可以把优先队列看作抽象接口，堆是实现它最高效的通用方案之一。工程里调用priority_queue/PriorityQueue/heapq，底层绝大多数就是堆。

优先队列适合那些“频繁有任务进入、又需要每次取出当前最重要一个任务”的场景。比如操作系统里的进程调度、负载均衡系统里按紧急程度排队、消息系统里按优先级投递。与其说学了堆不如说学会了优先队列，这个心智模型可以直接套到业务里。

5.2 TopK问题：大小根堆怎么选

海量数据中找前K个最大值，是堆在面试里出现频率最高的题型。我先把结论放这儿：要前K大，就维护一个大小为K的小根堆。

做法是一边遍历数据，一边维护这个堆。堆里始终只存“当前见过的K个最大元素”，堆顶则是这K个里最小的那个。新来的元素如果比堆顶大，说明它应当进入前K，就把堆顶弹出，把它插进去；如果比堆顶小，直接忽略。

为什么不是用大根堆去存前K大？因为大根堆堆顶是最大的，你无法判断新进来一个普通元素到底能不能挤进前K，得把K个候选全存下来才能比较，这样堆会膨胀到和全集一样大，完全失去了“只关心前K”的优势。反过来，最小堆的堆顶正好是候选集里的“门槛”，没迈过门槛的直接淘汰，存储量就能严格控制在K以内。

代码片段：

python复制import heapq

def top_k_largest(nums, k):
    heap = []
    for x in nums:
        if len(heap) < k:
            heapq.heappush(heap, x)
        elif x > heap[0]:
            heapq.heapreplace(heap, x)
    # 堆里是前K大，但未必有序
    return heap

同理，找前K小元素时，把元素取负后放到堆里，或借助其他语言的最大堆实现反向思路。

5.3 双堆模型：数据流中位数和滑动窗口

单个堆解决“一个极值”，如果你想动态维护中位数，就需要两个堆：

• 一个最大堆lo，存数据流中较小的一半；
• 一个最小堆hi，存数据流中较大的一半。

始终保持二者的元素数量差不超过1，那么中位数要么是lo的堆顶，要么是lo堆顶和hi堆顶的均值。

Python版本可以用heapq加负数模拟最大堆：

python复制import heapq

lo = []  # 最大堆，实际存元素取负后的结果
hi = []  # 最小堆，存较大一半

def add_num(num):
    heapq.heappush(lo, -num)
    # 为了保证 lo 中所有元素都不大于 hi 中的元素，先弹一个最大堆顶放到最小堆
    heapq.heappush(hi, -heapq.heappop(lo))
    if len(lo) < len(hi):
        heapq.heappush(lo, -heapq.heappop(hi))

def find_median():
    if len(lo) > len(hi):
        return -lo[0]
    return (-lo[0] + hi[0]) / 2

这招在“数据流均值”“滑动窗口中的中位数”“订单实时价格分位数”等需求里非常通用。一个堆的题目大概率不值钱，双堆交叉才是拉开梯度的考点。滑动窗口里的最大值也有类似的懒删除处理思路，用一个堆加一个过期元素的删除标记，比维护单调队列更容易扩展到变长窗口。

5.4 堆优化Dijkstra和定时任务

Dijkstra算法在找当前距离起点最近且未确认的节点时，朴素写法是每次遍历所有顶点，复杂度是O(V^2)；用最小堆可以把这个“找最小”的步骤降到O(log V)，整体接近O((V+E) log V)。

核心技巧是：堆里存的候选节点可能被重复加入多次。当某条边松弛后，更小的dist被发现，同个节点的旧版本仍然留在堆中。你不需要去删旧的，只需要在使用时判断一下这个堆顶的dist是否和当前记录的dist一致，不一致就直接丢弃，英文圈叫lazy deletion。很多新手第一次实现时，担心的不是超时而是“为什么堆里同一个节点有多个副本”，到这一步想通就行，这不算错误，是懒删除的常见形态。

定时器系统也常用最小堆。每个定时任务就是“到期时间戳+回调函数”，堆顶永远是下一个最先到期的任务。每次创建定时器O(log n)，取最近到期任务O(1)，触发后弹出再调整O(log n)。如果你做个轻量级调度器或连接池心跳管理，用这个方案配合事件循环，代码能写得非常干净。

6. 内存里的堆、栈与“堆外内存”：概念不清的源头

6.1 进程内存布局中的栈和堆

热搜词里出现“栈和堆”，大概率是操作系统或编程语言入门时被这两个词搞糊涂了。把它们放一张表里看就清楚很多：

栈“快”，核心原因是栈帧的分配模式极其规则：函数调用的帧是一个压一个，返回时整体弹栈，不需要像堆那样扫描空闲链表、处理碎片。在JVM里，栈上还可能发生逃逸分析后对象的标量替换，但这已经是很深的话题，入门阶段只需要先建立一个直觉：栈管理规则简单所以快，堆灵活但代价更高。

6.2 堆外内存、OOM与构建工具的“堆空间不足”

“堆外内存”这个词一般是Java生态里冒出来的。JVM的堆内存受-Xmx控制，GC能管理它；而堆外内存指的是通过ByteBuffer.allocateDirect等方式在JVM堆之外申请的内存，由操作系统直接管理，常见于Netty、Kafka等做网络IO的高性能框架。堆外内存的好处是避开GC扫描，同时减少IO读写时在堆内和堆外之间的拷贝；代价是回收更麻烦，一旦泄漏，JVM的堆看起来很正常，进程却可能被系统按内存占用异常杀掉。

至于“编译器的堆空间不足”，我见过最多的场景根本不是手写编译器的错误，而是Node构建、Android/Gradle构建时JVM进程默认堆太小。

Node.js构建JavaScript代码时如果报JavaScript heap out of memory，可以在命令前设置：

bash复制export NODE_OPTIONS=--max-old-space-size=4096

如果是Java服务启动时频繁OOM，优先关注启动参数里的-Xmx和-Xms，并打开堆转储：

bash复制java -Xms512m -Xmx4g -XX:+HeapDumpOnOutOfMemoryError -jar app.jar

堆设置不是越大越好。容器场景下如果-Xmx设置得比容器的内存上限还高，JVM还没来得及启动完，进程就可能因为整机内存超限被直接杀掉。

6.3 别把虚拟机参数当成数据结构参数

也有初学JVM的同学看到-Xms和-Xmx里的“heap”字样，以为是在调数据结构堆，其实完全两个维度：-Xmx控制运行时堆区的内存上限，数据结构堆只不过恰好也常被放进运行时的堆区里。它们是“地域”和“建筑”的关系。一个Java对象内部的PriorityQueue，同样要消耗JVM堆里的内存，但PriorityQueue内部的逻辑结构是二叉堆，物理存储则是一个数组。

有时候搜“redis cluster bus 远程堆 uaf 漏洞”这类内容，看到“堆”字又会吓一跳。这类安全公告里的“堆”通常指运行时内存堆或某个语言运行时内存布局中的堆破坏问题，跟“二叉堆”算法没直接关系，面对这类信息更建议直接跟进官方安全公告和升级补丁，不必自己在业务代码里“防”。

7. 我在这类排查和代码审查里踩过的坑

7.1 坑一：把堆当成有序数据结构直接查找

很多代码在需要“第二小的元素”时，天真地写了heap[1]。小根堆里heap[0]确实是全局最小，但heap[1]不是第二小。在小根堆中，第二小的元素会在堆顶弹出后的堆顶出现，而堆顶弹出前，第二小可能在heap[1]，也可能在heap[2]，无法通过固定下标判断。

需要从堆里拿“前几个最小”时，正规做法是，要么把它们逐个pop出来收集，要么干脆用容量K的堆维护TopK，不要让“数组下标”这个概念继续误导你。

7.2 坑二：在程序里创建海量小堆对象

堆结构本身的每次插入删除都是O(log n)，但这个n如果很小，堆的开销大头反而在对象创建和数据结构分配上。我有一次负责一个高频交易数据的实时过滤器，每个请求都新建一个PriorityQueue去维护当前窗口的Top10，结果性能迟迟上不去。

后来改成复用同一个数组底层，通过heapq.heapify()批量重置，或者直接用懒删除，性能立刻好了一个数量级。真正写频繁请求路径时，结构体分配要能省则省，能复用就复用。“堆很高效”的前提是你没有在循环里疯狂new堆。

7.3 坑三：堆和优先队列混用时搞反大小根语义

不同语言、不同容器对“优先”的定义是不同的。std::priority_queue默认是大根堆，也就是取出来的是最大元素；Java的PriorityQueue默认是小根堆，取出来的是最小元素；Python的heapq也是小根堆。如果不确定，别靠记忆，写一个最小例子跑一下或者查一下文档。

另一种低级错误是修改堆里的元素之后忘掉恢复堆序。Python的heapq提供的函数不是自动维护的，你直接改heap[3]，它没有魔法帮你重新上浮或下沉，堆序会静默地坏掉。遇到需要随机访问堆内元素并修改的场景，要么自己实现堆，在里面维护一个“元素到下标”的映射，要么用懒删除兜底。

7.4 排查内存堆异常时的顺序建议

如果真的遇到进程内存不断上涨、OOM频发，不要一上来就怀疑某个算法结构，先按下面顺序做一轮基础检查：

1. 通过监控看是堆内内存涨，还是堆外内存/容器RSS涨。
2. Java进程用jmap -heap看堆配置，用jstat -gcutil看GC频率；Node进程看process.memoryUsage()。
3. 如果堆内涨但有富余，怀疑对象泄漏，抓一份heap dump分析大对象和存活对象；
4. 如果堆配置正常但容器反复被杀，怀疑堆外内存、线程栈或本地内存没有上限，逐个排查。

亲手记录一次线上问题后，你会发现这些概念之间确实有联系：很多底层工具用“堆”实现优先队列，而每个节点最终又分配在“内存堆”里，两个堆通过一个运行时系统关联起来。

最后再分享一个我调试手写堆的习惯：小例子优先。但凡怀疑自己的堆实现有问题，永远先拿[4, 10, 3, 5, 1]这样的小数组，在纸上模拟一遍插入、弹出、堆化，然后对着日志打印每次调整后的完整数组。数组模式对不对一眼就能看出来。等小数组跑通，再上10万随机数据进行对拍，和标准库的堆逐项比较结果。堆的代码虽然短，边界条件却非常容易错，白板上的自信和实际跑通之间，往往就差这样一轮小步验证。