C++实现带路径压缩的并查集 _ 连通分量统计与优化【源码】

C++实现带路径压缩的并查集：连通分量统计与优化【源码】

为什么路径压缩不能只写 parent[x] = find(parent[x])

这大概是实现并查集时最容易踩进去的坑。乍一看，递归调用后直接把父节点指向根节点，逻辑似乎很清晰。但问题恰恰出在这里：必须在find函数返回之前完成所有节点的挂载操作。如果顺序错了，路径压缩就形同虚设，中间节点依然指向旧的父节点，下次查询时还得重新遍历那条冗长的链。

反映在现象上就是：调用find之后，树的高度并没有显著降低；经过多次union操作后，查询的复杂度可能还是O(n)级别；性能测试会显示连通性判断的速度不升反降。

• 正确的执行顺序是：递归到底，拿到根节点 → 在回溯的过程中，逐层将parent[x]设置为根节点。
• 切忌写成return parent[x] = find(parent[x])这种看似简洁的形式。因为在C++中，表达式的求值顺序并不保证先计算右边部分。
• 最稳妥的写法是显式分两步：int root = find(parent[x]); parent[x] = root; return root;。清晰，且万无一失。

union里按秩合并（rank）和按大小合并（size）怎么选

路径压缩本身已经能大幅压扁树的高度，但它会带来一个副作用：rank所记录的“秩”会因此失真——压缩之后，树的实际高度很可能已经不等于rank值了。所以，在同时使用路径压缩的实践中，更推荐按大小合并。size记录的是子树中真实的节点数量，不受路径压缩的影响，能更稳定地控制树的平衡性。

什么时候该用size？当你需要频繁查询连通分量的大小（例如计算图中最大连通块的节点数，或者统计岛屿面积），或者对并查集的最终结构有较高的稳定性要求时，size比rank要可靠得多。

• 按大小合并：比较size[root_a]和size[root_b]，将较小树的根指向较大树的根，然后更新size[root_b] += size[root_a]。
• 按秩合并：主要用于理论上的深度控制，其rank值不会随路径压缩而更新，适用于只进行连通性判断且对内存极其敏感的场景。
• 两者在理论上可以共存，但通常没有必要。优先选择size，它还能额外提供一个便利的get_component_size(int x)查询功能。

初始化与连通分量计数怎么保持同步

另一个常见的疏忽在于连通分量的计数。很多实现图省事，将初始数量硬编码为节点数n。然而，如果后续的union操作合并了两个已经在同一集合中的点（即无效合并），计数就会出错。因此，必须确保只在真正发生了一次有效的合并时，才将计数减一。

典型的错误场景是：在union(a, b)函数中，没有先判断find(a) != find(b)就直接执行合并逻辑与计数递减，导致count被重复扣减。最终，get_count()返回的值可能为负，或者远小于实际的连通分量数。

• 每次执行union前，必须检查两个元素是否已属于同一集合：if (root_a == root_b) return false;
• 仅当上述条件不成立时，才去更新parent、size以及count。
• 如果需要支持操作撤销（例如处理离线查询），计数机制会更复杂，但这超出了基础实现的需求。

C++实现要注意的内存与内联细节

标准的教科书式find实现是递归的，在数据量小的时候没问题。但是，当节点数量超过10⁵级别时，递归调用存在栈溢出的风险。在生产环境中，更推荐使用迭代版本的find。此外，所有热点路径上的函数（主要是find和union）应该声明为inline，以避免虚函数或动态调度带来的额外开销。

这些优化带来的性能影响是实实在在的：一个未内联的find函数，在像Kruskal算法这样需要高频调用的场景下，可能会产生超过15%的额外函数调用开销。而迭代版虽然代码稍长，但彻底消除了栈风险，并且对CPU的分支预测更加友好。

• 迭代版find需要遍历两次：第一次循环找到根节点，第二次循环进行路径压缩。不能边找边压缩，否则会丢失真正的根节点信息。
• 使用std::vector来存储parent和size数组，避免手动管理new[]和delete[]。这不仅防止了内存泄漏，也保证了更好的缓存友好性。
• 在构造函数中，用resize(n)配合iota(parent.begin(), parent.end(), 0)进行初始化，通常比手写循环要更快。