Kruskal算法通过贪心策略选择不构成环的最小权重边构建最小生成树，使用并查集高效检测环，时间复杂度为O(E log E)，在稀疏图中表现更优。
Kruskal算法是一种寻找给定连通加权图中最小生成树（MST）的经典算法。它的核心思想非常直观：贪心地选择边，但要确保不形成环。Kruskal的实现步骤围绕着边的排序和高效地判断是否形成环（通常通过并查集）展开。
Kruskal算法的实现，在我看来，其实是“贪心”思想的一种优雅体现。它不关心节点，只关注边，这和Prim算法那种以节点为中心的扩展方式很不一样。具体来说，我们把图里所有的边都拿出来，按权重从小到大排个序。然后，我们一条一条地去“捡”这些边。每捡一条边，我们都要问自己一个问题：这条边会不会让我的生成树形成一个圈？如果会，那这条边就不要了；如果不会，那就把它加进来。这个“会不会形成圈”的判断，就是通过并查集（Disjoint Set Union, DSU）数据结构来高效完成的。当我们把足够多的边（对于一个有V个顶点的图，就是V-1条边）加进来，并且没有形成环时，我们就得到了最小生成树。
伪代码大致是这样：
- 创建一个空的边列表，用于存放MST的边。
- 初始化并查集：每个顶点都是一个独立的集合。
- 将图中所有的边按权重升序排序。
- 遍历排序后的边：
- 对于当前边 (u, v)，如果 u 和 v 不在同一个集合中（即加入这条边不会形成环），
- 将这条边加入MST边列表。
- 合并 u 和 v 所在的集合。
- 重复直到MST边列表包含 V-1 条边，或者所有边都已检查。
Kruskal算法与Prim算法在解决最小生成树问题上有何异同？
当我第一次接触最小生成树问题时，Kruskal和Prim算法常常被拿来一起比较，它们都遵循贪心策略，但“贪”的方式却截然不同。Kruskal是典型的“边导向”算法，它关注的是图中的所有边，将其按权重排序后，逐一考虑是否能加入MST，核心是避免形成环。这种全局性的视角，让它在处理一些特定图结构时显得特别高效。
而Prim算法则是“点导向”的。它从一个起始顶点开始，逐步扩展MST，每次都选择连接当前MST中某个顶点到外部顶点且权重最小的边。这就像是从一个点开始“生长”一棵树，一步步把最近的“邻居”拉进来。Prim通常用优先队列来实现，来高效地找到下一条最短的边。
具体来说，它们的异同体现在：
- 贪心策略的侧重点： Kruskal是基于“边”的贪心，始终选择当前可用的最短边，只要不构成环。Prim是基于“点”的贪心，始终选择连接当前MST和外部顶点的最短边。
- 实现方式： Kruskal高度依赖于对边的排序和并查集来判断环。Prim则通常依赖于优先队列来选择最短的边，并维护每个顶点到MST的最小距离。
- 适用场景： Kruskal在稀疏图（边数E远小于顶点数V的平方）上表现通常更优，因为它的主要开销在于对边的排序，而Prim在稠密图（边数E接近顶点数V的平方）上可能更具优势，因为它对边的遍历和更新操作相对频繁。但实际上，现代图算法库通常会根据图的密度自动选择或优化。
如何高效判断Kruskal算法中是否会形成环？并查集在此扮演什么角色？
Kruskal算法最巧妙的地方，我觉得就是它如何高效地判断“加这条边会不会形成环”。如果只是简单地遍历已加入的边来检查，那效率会非常低。而并查集（Disjoint Set Union, DSU）数据结构，简直就是为这个问题量身定制的。
并查集的核心思想是维护一系列不相交的集合。在Kruskal算法中，每个顶点最初都属于一个独立的集合。当我们考虑加入一条边
(u, v)时：
-
查找操作 (Find): 我们通过
find(u)
和find(v)
操作，查找顶点u
和v
各自所属集合的代表元素（通常是根节点）。 -
判断是否成环： 如果
find(u)
的结果等于find(v)
的结果，这意味着u
和v
已经处于同一个集合中。此时，如果再加入边(u, v)
，就必然会形成一个环。所以，这条边我们不要。 -
合并操作 (Union): 如果
find(u)
和find(v)
的结果不同，说明u
和v
目前分属不同的集合。加入边(u, v)
不会形成环，那么我们就把这条边加入到MST中，并且通过union(u, v)
操作，将u
和v
所在的两个集合合并成一个大集合。
为了提高并查集的效率，通常会采用两种优化策略：
-
路径压缩 (Path Compression): 在
find
操作中，将查询路径上的所有节点的父节点直接指向根节点，大大减少后续查询的时间。 -
按秩合并/按大小合并 (Union by Rank/Size): 在
union
操作中，总是将较小的树合并到较大的树下面（或将深度较浅的树合并到深度较深的树下面），以保持树的平衡，避免退化成链表。
通过这些优化，并查集的单次操作时间复杂度可以接近常数时间（反阿克曼函数α(n)是一个增长极其缓慢的函数，在实际应用中可以看作常数），这使得Kruskal算法在处理大规模图时依然非常高效。
Kruskal算法的时间复杂度是多少？在哪些场景下它表现更优？
谈到算法的效率，时间复杂度总是绕不开的话题。Kruskal算法的时间复杂度主要由两个部分决定：
-
边的排序： 这是最显著的一步。如果图中有E条边，对这些边进行排序通常需要
O(E log E)
的时间。这是因为我们使用了比较排序算法，比如快速排序或归并排序。 -
并查集操作： 在排序之后，我们需要遍历所有E条边，对每条边进行一次
find
操作和一次union
操作（如果需要合并）。在采用了路径压缩和按秩合并/按大小合并优化的并查集数据结构下，E次操作的总时间复杂度近似为O(E * α(V))
，其中v
是顶点的数量，α
是反阿克曼函数。由于α(V)
增长极其缓慢，在实际应用中，它几乎可以被视为一个常数（通常小于5），所以这部分的时间复杂度可以近似看作O(E)
。
综合来看，Kruskal算法的总时间复杂度是
O(E log E + E * α(V))。因为
E log E通常大于
E * α(V)，所以Kruskal算法的主导时间复杂度是
O(E log E)。
至于它在哪些场景下表现更优，我的经验是：
-
稀疏图： 当图的边数E相对较少，远小于顶点数V的平方时（即
E << V^2
），Kruskal算法的优势会比较明显。因为Prim算法在稠密图上可能需要频繁更新优先队列，而Kruskal的主要开销在于排序，这在边数不多时是高效的。 - 边列表容易获取和排序： 如果你的图数据结构天然就是边的列表，或者很容易转换成边的列表并进行排序，那么Kruskal的实现会非常直观和方便。
- 分布式或并行环境： Kruskal算法的排序步骤可以相对容易地并行化。虽然并查集的操作本质上是串行的，但对于大规模图，如果能将边的排序这一大块计算分摊到多个核心或机器上，Kruskal会展现出其在并行计算中的潜力。
总之，Kruskal算法以其简洁的贪心思想和高效的并查集辅助，在处理各种最小生成树问题时都表现出色，尤其是在边不那么密集的图中，它是一个非常可靠的选择。
