观前提醒：文章内容为本人在收集资料后的现学现卖，文章内容也很大程度上参照了其他大佬的思路，如果想更好理解斐波那契堆，推荐移步更清晰的讲解：
油管原主www.youtube.com/watch?v=6Jx…
b站搬运www.bilibili.com/video/BV1Wy…
在介绍斐波那契堆前，有必要先复习一下一般的二叉堆优先队列。
优先队列
性质
- 动态维护元素集合，快速访问/删除最小（或最大）元素
- 核心操作：
GetMin：返回最小元素Insert：插入新元素ExtractMin：删除并返回最小元素DecreaseKey：降低某元素的关键字值
对优先队列有所了解的话，以上优先队列的操作过程和复杂度理应不陌生，就不多展开了。
简单来说斐波那契堆就是结构复杂的优先队列，斐波那契堆的懒惰合并和延迟剪枝等策略，本质是为了优化优先队列的接口操作。若不熟悉优先队列的设计目的和核心操作，下面的内容可能会很难懂。
斐波那契堆的结构与性质
核心结构：
-
多根树森林：由多棵最小堆有序树（父节点 ≤ 子节点）组成
-
根链表：所有树根通过双向循环链表连接，含最小根指针
-
节点结构：
struct Node {
int key; // 关键字
int degree; // 子节点数
bool mark; // 是否失去过子节点
Node *parent; // 父指针
Node *child; // 任意子节点
Node *left, *right; // 兄弟指针（双向链表）
};
- 堆结构：
Min
↓
根链表: [A] ↔ [B] ↔ [C] ↔ [D] (双向循环链表)
| / \ |
[E] [F] [G] [H]
| / \
[I] [J] [K]
关键性质：
- 懒惰（Lazy）策略：
Insert插入新节点时直接加入根链表，不立即合并树DecreaseKey时可能剪枝但不立即调整结构- 延迟的合并/剪枝操作积累到
ExtractMin时统一处理
关于这个懒惰具体是怎么个懒法，我接下来会慢慢说明。简而言之，对于斐波那契堆来说只要维护好Min的指向就能在O(1)内完成获取最小值，其他的操作暂且都可以草率地对待，留到ExtractMin操作时再收拾烂摊子。
1. Insert操作过程与复杂度
操作过程：
- 创建新节点
x，初始化key, degree=0, mark=false - 将
x插入根链表中（修改相邻节点的左右指针） - 更新最小根指针（若
x.key < min.key）
示例：
Min
↓
根链表: [A] ↔ [B] ↔ [C] ↔ [D] ↔ [New](直接插入根链表就是最懒的策略)
| / \ |
[E] [F] [G] [H]
| / \
[I] [J] [K]
插入New: [A] ↔ [B] ↔ [C] ↔ [D] ↔ [New] (若 New<A 则 min 指向 New)
复杂度分析：
- 实际代价：O(1)（仅修改指针）
- 均摊代价：O(1)（势能法证明）
但长此以往就会变成这样
根链表: [A] ↔ [B] ↔ [C] ↔ [D] ↔ [New 1] ↔ [New 2] ↔ .... ↔ [New N]
| / \ |
[E] [F] [G] [H]
| / \
[I] [J] [K]
根部将变得非常非常长，弹出Min后如果就这么放着，最坏情况下，ExtractMin 需要遍历所有 t 棵树（例如连续插入 n 个节点后调用 ExtractMin，t = n），复杂度为 O(n)。
斐波那契堆中的度数
在斐波那契堆中，度数（degree） 是每个节点的一个核心属性，它表示该节点的直接子节点数量。度数不仅是节点结构的描述符，更是保证斐波那契堆高效性的关键机制。
度数的定义与基本性质
- 定义： 节点
x的度数x.degree= 其子节点链表中的子节点数量。 - 示例：
(0) (1) (2) (1)
根链表: [A] ↔ [B] ↔ [C] ↔ [D] (双向循环链表)
| / \ |
(0) (1) (0) (2)
[E] [F] [G] [H]
| / \
(0) (0) (0)
[I] [J] [K]
2. ExtractMin的操作与复杂度分析
操作步骤：
- 移除最小根：
- 从根链表中删除
z：O(1) - 剪下子节点链接到根链表：
- 最小根节点有
d个子节点（度数d）
- 最小根节点有
- 时间复杂度：O(D(n))（d<=最大度数D(n)，所以可以确定复杂度的上限）
删除C：
Min(待弹出)
↓
根链表: [A] ↔ [B] ↔ [C] ↔ [D]
| / \ |
[E] [F] [G] [H]
| / \
[I] [J] [K]
->
根链表: [A] ↔ [B] ↔ [D] ↔ [F] ↔ [G] (子节点F，G直接接入根链表)
| | |
[E] [H] [I]
/ \
[J] [K]
2. 合并相同度数的树 (Consolidate) ：
- 遍历根链表（
A[]数组大小要装下所有度数的数，大小至少为D(n)，并遍历总量为t的树） - 合并度数相同的树（合并操作使树的数量-1，也就是说复杂度最多与树的棵数
t相同）- 原因： 合并操作要尽量使树的数量t和最大度数D(n)都尽量最小，而方法就是合并相同度数的树，直至没有相同度数的树，那么在清理过后的树最多只有最大度数+1棵。
- 时间复杂度：O(t + D(n))
根链表: [A] [B] [C] [D] [E]
| / \ / \
[F] [G] [H] [I] [J]
-> 合并AB以及DE
[A] [C] [D]
| | / | \
[B] [F] [G] [H] [E]
/ \
[I] [J]
-> 合并AC
[A] [D]
/ \ / | \
[B] [C] [G] [H] [E]
| / \
[F] [I] [J]
没有相同度数的树的话，合并结束
在 ExtractMin 中合并相同度数的树：
def Consolidate():
A = [None] * (D(n) + 1) # 基于度数创建数组
for x in root_list:
d = x.degree
while A[d] is not None:
y = A[d] # 找到另一棵度数相同的树
if x.key > y.key:
swap(x, y) # 保证 x 为根
Link(y, x) # 将 y 链接为 x 的子节点
A[d] = None
d += 1 # 度数增加
A[d] = x
此处度数的意义：
- 快速定位相同度数的树（数组索引 = 度数）
- 合并后新树的度数 = 原度数 + 1
- 重建根链表：
- 收集
A[]中非空节点，形成新根链表- 经分析可知，节点数量与合并过后的树的棵树，即与D(n)有关。
- 更新最小根指针
- 时间复杂度：O(D(n))
ExtractMin复杂度分析：
- 移除最小根并提升子节点：O(D(n))（最小根最多D(n)个子节点）
- 合并操作：O(t + D(n))（t为合并前根链表树的数量）
- 重建：O(D(n))（最小根最多D(n)个子节点）
实际代价总和： O(D(n)) + O(t + D(n)) + O(D(n)) = O(t + D(n))
结论：ExtractMin复杂度只与树的棵数和最大度数有关。
但通过 均摊(斐波那契堆的核心逻辑) 分析，根链表中的树数量 t 的代价将被完全抵消，最终复杂度降为 O(D(n)) = O(log n) 。
所谓最大度数 D(n) 是全局理论上限，由当前节点总数 n 决定，与操作临时状态无关。
- 它保证了无论堆如何动态变化，最大度数始终受控（
O(log n)），从而维持ExtractMin的高效性。 - 合并操作只是强制让树的数量
t适配D(n)，而非重新计算D(n)。
根链表: [1] [1] [1] [1] [1]
| / \ / | \ / / / \
[2] [2] [3] [2] [3] [5] [2] [3] [5] [9]
| | / \ | / \ / | \
[4] [4][6][7] [4] [6][7] [10] [11] [13]
| | | / \
[8] [8] [12][14][15]
|
[16]
如图，32个节点最终构成5棵树，可观察到 D(n) = log n。
可以把 D(n) 想象成一座房子的最大楼层数：
n：当前房子里住的人数。D(n)：根据建筑法规（斐波那契堆的约束），楼层数不能超过log n层。- 人越多（
n越大），允许的楼层（度数）越高，但增长非常缓慢（对数级）。
- 人越多（
- 合并操作：像定期整理房间，把杂物堆（多余的树）压缩到符合楼层限制。
均摊的概念：斐波那契堆的核心逻辑
所谓的均摊分析的核心思想就是：将高代价操作的开销均摊到整个操作序列中，保证序列的平均代价最优。
后面会着重解释，暂且按下不表。总之先记住：
在斐波那契堆中，均摊就是将ExtractMin的开销分摊算在其他操作(Insert 和 DecreaseKey)的开销上，让其他操作的复杂度保留在常数级的同时，让ExtractMin的复杂度保留在 log n级。
ExtractMin的均摊
人话总结：ExtractMin进行的至多t次的合并操作的复杂度被算到了此前的所有Insert操作上。
想象你有一张信用卡：
- 平时小额消费（Insert） ：每次花钱（插入节点）只记录账单，不立刻还款（不立刻合并树），所以操作很快（O(1)）。
- 月底还款日（ExtractMin） ：一次性还清所有欠款（合并树），虽然还款过程较慢，但把总开销均摊到每天的小额消费上，整体平均每天的花费仍然可控。
总结
Insert的 O(1) 是“假象” ：它只是延迟了合并的开销。ExtractMin的 O(log n) 是“真还债” ：合并的开销都算在了此前的Insert操作上，保证均摊高效。
关键点：
- 懒惰操作（平时不合并）积累的“债务”（树的数量
t），在关键时刻（ExtractMin）通过合并一次性解决。 - 树的数量 t 被约束：
- 合并后，
t' ≤ D(n) + 1（因为度数唯一，类似“合并后最多剩 D(n) 种不同的扑克牌叠”）。 - D(n) 是瓶颈：无论之前有多少树（t），合并后都会压缩到 D(n) 的规模。
- 合并后，
结论: 最终复杂度 只与 D(n) 相关，而 D(n) = O(log n) 则是由斐波那契堆的度数约束保证的。
3. DecreaseKey的处理与复杂度分析
将节点 x 的键值从 k 降低到 k' （k' < k），操作流程如下：
1. 降低键值
- 直接修改
x.key = k'。 - 如果
x不是根节点，且x.key < x.parent.key（违反最小堆性质），则触发 剪枝（Cut） 。
2. 剪枝（Cut）
- 将
x从父节点y的子链表中移除。 - 将
x添加到根链表中，并清除x.mark（因为它现在是根，不再有父节点）。 - 减少
y.degree（因为y失去了一个子节点）。 - 检查
y是否需要级联剪枝：- 如果
y未被标记过（y.mark == false），则标记它（y.mark = true），操作结束。 - 如果
y已被标记（y.mark == true），则递归地对y执行剪枝（即 级联剪枝，Cascading Cut）。
- 如果
3. 更新最小指针
- 如果
x.key < H.min.key，更新H.min = x。
原本的堆：
[A] [D]
| / | \
[B] [G] [H] [E]
/ \
[I] [J]
|
[K]
-> 假设J违反了堆性质，剪掉J
[A] [D] [J]
/ \ / | \ |
[B] [C] [G] [H] [E](J的原父节点已标记) [K]
| |
[F] [I]
如果J<Min，更新Min
标记机制的作用
控制级联剪枝的深度
-
问题：如果每次
DecreaseKey都立即剪枝所有违反堆性质的节点，最坏情况下可能导致 O(log n) 次递归剪枝（例如长链父子结构），使得单次DecreaseKey的复杂度退化为 O(log n)。 -
解决方案：标记机制通过以下规则限制剪枝：
- 首次失去子节点：仅标记父节点（
mark = true），不立即剪枝。 - 第二次失去子节点：若父节点已被标记，则触发剪枝，并递归检查祖父节点。
- 首次失去子节点：仅标记父节点（
-
标记机制确保：
- 每个节点最多被剪枝一次（因为剪枝后它变为根，不再有父节点）。
- 每次
DecreaseKey只有常数次剪枝需要实际执行（其余通过势能抵消）。
-
为剪枝提供限制：
- 级联剪枝确保每个节点至多失去一个子节点后才被剪枝
- 避免树结构被过度破坏，保证
D(n) = O(log n)
DecreaseKey的均摊
时间复杂度分析
- 降低键值：O(1)（直接修改）。
- 剪枝：每次剪枝需要 O(1) 时间（修改指针）。
- 级联剪枝：即便有标记机制，最坏情况下可能递归剪枝 O(log n) 次（因为树高度 ≤ D(n) = O(log n)）。
最坏情况：O(log n)（如果触发长链的级联剪枝）。
但与ExtractMin类似，在均摊后DecreaseKey可以达到O(1)，因为前面已经在解释ExtractMin时说过均摊的概念了，这里直接说结论。
人话总结：级联剪枝的O(log n)被均摊到了此前其他的DecreaseKey操作上，也就是有 ‘分期付款’ 提前垫付。
- 原因：级联剪枝的
k次剪枝中，至少有k-1个节点原先被标记，那么此前至少有过k-1次DecreaseKey操作，已知每次操作至多增加一个被标记的节点，因此这么一均摊就变成了O(1)。
4. 均摊分析（Amortized Analysis）
最后再让我们重点强调一下要斐波那契堆的重中之重。
均摊分析的核心思想是：将高代价操作的开销均摊到整个操作序列中，允许单次操作耗时较高，但保证序列操作的平均代价低。
代价是如何“分摊”到 Insert 和 DecreaseKey的？
(1) Insert 操作
- 实际行为：直接插一个节点到根链表（树数量
t += 1）。 - 分摊的成本：ΔΦ = +1（因为
t增加了 1）。 - 均摊代价：O(1)（实际） + 1（成本） = O(1) 。
- 意义：
Insert提前支付了未来ExtractMin合并这棵树的“潜在开销”，但每次只付 O(1)。
(2) DecreaseKey 操作
- 实际行为：可能剪枝一个节点（
t += 1），并可能标记父节点（m += 1）。 - 分摊的成本：
- 最坏情况：ΔΦ = +2（
t +1，m +1）。 - 期望情况：由于标记机制限制级联，均摊后 ΔΦ ≈ +1。
- 最坏情况：ΔΦ = +2（
- 均摊代价：O(1)（实际） + O(1)（成本） = O(1) 。
- 意义：
DecreaseKey不仅支付了当前剪枝的开销，还预存了未来级联剪枝的势能（通过m）。
为什么 Insert 和 DecreaseKey 仍是 O(1)？
Insert每次只增加 1 代价成本（t +1）。DecreaseKey平均增加约 1~2 代价成本（t +1或m +1）。
这些“小额存款” ： 足够覆盖 ExtractMin 中 O(t) 的合并开销，因此 Insert 和 DecreaseKey 无需额外付费，均摊后仍是 O(1)。
ExtractMin 的 t 被抵消了吗？
-
实际开销：O(t + D(n))（遍历
t棵树 + 合并D(n)次）。 -
均摊后的开销：O(D(n)) = O(log n) （
t被其他操作预支的存款抵销）。 -
最大度数的变化：
- 合并后树数量
t' ≤ D(n)+1（因为t大幅减少）。
- 合并后树数量
-
关键结论：
t的代价被势能完全抵消，最终复杂度仅由D(n)（最大度数）决定，而D(n) = O(\log n)。
顺便提一下斐波那契堆的势能函数 Φ(H) = t(H) + 2m(H) ：
t(H)：当前堆中树的数量（反映“懒惰合并”积累的债务）。m(H)：被标记节点的数量（反映“延迟剪枝”的潜在代价）。
作用：记录未处理的“懒惰操作”积累的代价，未来由高开销操作（如 ExtractMin）偿还。
设计意义：
t(H)反映“懒惰合并”的代价积累（树越多，后续ExtractMin代价越高）m(H)反映“延迟剪枝”的代价积累（标记节点越多，级联剪枝代价越高）- 系数
2确保DecreaseKey的均摊代价为 O(1)
5. 树的指数增长与斐波那契数列
对啊！说了那么多，斐波那契堆的斐波那契在哪里啊？
但在那之前我们先讨论一个问题：节点度数是对数增长的吗？
已知如果不考虑DecreaseKey对树结构的破坏，那原本的话 树的总节点数n = 2 ^ d(最大度数 = log n)。
能得到的树的结构应该如下:
根链表: [1] [1] [1] [1] [1]
| / \ / | \ / / / \
[2] [2] [3] [2] [3] [5] [2] [3] [5] [9]
| | / \ | / \ / | \
[4] [4][6][7] [4] [6][7] [10] [11] [13]
| | | / \
[8] [8] [12][14][15]
|
[16]
那再讨论一个问题：树的节点数是指数增长的吗？
同理 树的节点数量 = 2 ^ d(最大度数 = log n)。不需过多解释，但如果考虑结构的破坏呢？
答案是：即便不完整的d度树，它的节点数量也按指数增长，但d不一定就是2了(d可以是大于1的任何数，比如1.3或1.9)。
前面DecreaseKey已经提到，一个节点最多失去一个子节点。
那么对于下图中的D节点，它的度数可能为多少？
[x]
/ / \ \
[A] [B] [C] [D]
既然最多失去一个节点，且在合并过程中在最右侧，也就是说它是在度数为3时与x合并的，其度数区间就会是[2, 3]。
按此理论推导就可以得出每种度数的在节点数最小时的树结构。
根链表: [1] [1] [1] [1] [1] [1]
| / \ / | \ / / \ \ / / / \ \
[2] [2] [3] [2] [3] [4] [2] [3] [4] [6] [2][3] [4] [6] [9]
| | / \ | / \ / | \
[5] [5][7][8] [5] [7][8] [10][11][12]
|
[13]
然后就能得出下图所示内容。
示意图：度数 vs. 最小子树大小
| 度数 k | 最小子树大小 | 斐波那契数 F_{k+2} |
|---|---|---|
| 0 | 1 | F₂ = 1 |
| 1 | 2 | F₃ = 2 |
| 2 | 3 | F₄ = 3 |
| 3 | 5 | F₅ = 5 |
| 4 | 8 | F₆ = 8 |
| ... | ... | ... |
| k | ≥ F_{k+2} | F_{k+2} |
结论：F(n) = F(n - 1) + F(n - 2)。
这不就是那个我们的熟悉斐波那契数列！
那么让我们回到那个问题：树的节点数是指数增长的吗？
核心性质：子树大小的下限
斐波那契堆规定，任意度数为 k 的节点，其子树大小（包含自身）至少为第 (k+2)个斐波那契数：
结论
斐波那契堆中的树是指数增长的，这是由斐波那契数列的递归约束直接决定的。这一性质保证了：
- 树的高度（或度数）严格受限于 O(\log n)O(logn)。
- 关键操作（如
ExtractMin）的复杂度稳定在 O(\log n)O(logn)。
正是这种指数增长，让斐波那契堆在“懒惰”中保持高效。
复杂度对比与应用
复杂度：
| 操作 | 二叉堆 (最坏) | 斐波那契堆 (均摊) |
|---|---|---|
GetMin | O(1) | O(1) |
Insert | O(log n) | O(1) |
ExtractMin | O(log n) | O(log n) |
DecreaseKey | O(log n) | O(1) |
可以看到性能上，斐波那契堆就像是优先队列的全面升级版！但是，当真如此吗？
1. 理论 vs. 现实的复杂度
-
均摊复杂度的隐藏代价：
- 斐波那契堆的 O(1)
Insert和DecreaseKey是均摊结果，单次操作可能触发高开销的延迟处理（如级联剪枝）。 - 实际运行时，常数因子较大（例如指针操作、标记维护等），导致在小规模数据上反而不如二叉堆快。
- 斐波那契堆的 O(1)
2. 实现复杂度与内存开销
-
实现难度：
- 斐波那契堆需要维护多根树、双向链表、标记位、度数计数等，代码复杂度远高于二叉堆（用数组即可实现）。
- 调试和维护成本高，易出错（例如指针操作失误导致内存泄漏）。
-
内存占用：
- 每个节点需存储
parent、child、left、right指针及mark标志，而二叉堆节点无需额外元数据。 - 对内存敏感的场景（如嵌入式系统），二叉堆更优。
- 每个节点需存储
3. 适用场景的限制
-
优势场景：
- 频繁
DecreaseKey或Merge的算法（如 Dijkstra 最短路径、Prim 最小生成树）。 - 大规模图处理（
n > 10^6），此时理论优势能抵消常数因子。
- 频繁
-
劣势场景：
- 数据规模较小或操作以
Insert/ExtractMin为主（如普通任务调度），二叉堆更简单高效。 - 需要确定性实时响应（均摊复杂度无法保证单次操作速度）。
- 数据规模较小或操作以
总结：为什么斐波那契堆未普及？
| 因素 | 斐波那契堆 | 二叉堆 |
|---|---|---|
| 理论复杂度 | 最优（均摊 O(1) 关键操作） | 部分操作 O(log n) |
| 实际运行速度 | 常数因子大，小数据慢 | 常数小，缓存友好 |
| 实现难度 | 高（多指针、标记位） | 低（数组即可） |
| 内存占用 | 高（每个节点需额外元数据） | 低（仅存储数据） |
| 适用场景 | 超大规模图算法 | 通用任务调度、中小规模数据 |
结论：
斐波那契堆仅仅是“理论上的强者”，但二叉堆依然是“实践中的赢家”。除非面对超大规模且频繁修改数据的场景，否则工程师通常会选择更简单、更稳定的二叉堆或其变种。
