当我们在程序中，对一个包含了“值”相同的元素的集合进行排序后，发现这些相同元素的“原始相对顺序”，发生了意外的变化，其根本原因在于，我们所使用的“排序算法”，其本身，是一种“不稳定”的算法。在计算机科学中，排序算法，被明确地，划分为“稳定”与“不稳定”两大类。这一问题的出现，主要源于以下五个核心因素：源于所使用的“排序算法”的“稳定性”不同、稳定排序算法能“保证”相等元素的原始相对顺序不变、不稳定排序算法在元素交换时“可能”会打乱该顺序、像“快速排序”等算法因其“长距离交换”的特性而“不稳定”、以及在需要“多级排序”的业务场景下，“稳定性”至关重要。
具体来说，一个“稳定”的排序算法，在设计上，就有一个明确的“承诺”：当它遇到两个值相等的元素时，它绝不会，去改变它们在排序前的“先后位置”。而一个“不稳定”的算法，则没有这个承诺，它在进行元素交换和移动以达到最终有序的过程中，可能会，也可能不会，保持原始的相对顺序。
一、问题的核心：“排序稳定性”
在深入探讨具体的算法之前，我们必须首先，建立一个关于“排序稳定性”的、清晰、准确的概念。这，是理解整个问题的“钥匙”。
1. 什么是排序稳定性？
排序算法的稳定性，是指，在一个待排序的序列中，如果存在多个具有相同“排序键”的元素，那么，在经过该算法排序后，这些具有相同键的元素，其彼此之间的“相对位置”，与它们在排序前，保持完全一致。
2. 一个具象化的例子
假设，我们有一个简单的、包含了学生信息的列表，我们需要，按照学生的“分数”，从高到低，进行排序。
原始列表（按报名先后顺序）：
{姓名: “张三”, 分数: 90}
{姓名: “李四”, 分数: 85}
{姓名: “王五”, 分数: 90}
{姓名: “赵六”, 分数: 80}
在这个列表中，“张三”和“王五”的分数，都是90，是“相同键”的元素。并且，在原始列表中，“张三”位于“王五”的前面。
经过“稳定”排序后的结果：
{姓名: “张三”, 分数: 90} <– 张三依然在王五前面
{姓名: “王五”, 分数: 90}
{姓名: “李四”, 分数: 85}
{姓名: “赵六”, 分数: 80}
经过“不稳定”排序后，一种“可能”的结果：
{姓名: “王五”, 分数: 90} <– 王五跑到了张三前面
{姓名: “张三”, 分数: 90}
{姓名: “李四”, 分数: 85}
{姓名: “赵六”, 分数: 80}
3. 排序稳定性为何重要？
在很多时候，相等元素的相对顺序，确实无关紧要。但在一些特定的、尤其是需要进行“多级排序”的业务场景中，稳定性，就变得至关重要。
场景：假设，我们需要，对一个员工列表，进行排序展示。首要的排序规则是，按“部门”的字母顺序；在部门相同的情况下，再按“入职日期”的先后顺序。
正确的做法：我们可以，先对整个列表，进行一次稳定的、按“入职日期”的排序。然后，再对这个结果，进行第二次稳定的、按“部门”的排序。
如果第二次排序是“不稳定”的，那么，在它处理那些“部门”相同的员工时，就可能会，完全打乱掉，我们在第一步中，好不容易，才排好的“入职日期”的顺序。
正如计算机科学泰斗高德纳（Donald Knuth）在其巨著《计算机程序设计艺术》中所强调的，算法，是计算机科学的核心。理解不同算法的、这些看似微小、实则深刻的内在特性差异，是专业开发者的基本功。
二、稳定排序的“守护者”们
这类算法，在其核心的“比较和交换”逻辑中，天然地，或通过精心的设计，保障了相等元素的相对顺序。
1. 冒泡排序 冒泡排序，通过反复地、只比较和交换“相邻”的两个元素，来逐步地，将最大（或最小）的元素，“冒”到序列的末尾。
稳定性保障：因为它只在左边元素 > 右边元素时，才进行交换，那么，对于两个值“相等”的元素，交换的条件，永远不会被满足。因此，一个本来就在前面的、值相同的元素，永远没有机会，和一个本来就在后面的、值相同的元素，发生位置交换。它天然地，就是稳定的。
2. 插入排序 插入排序，通过构建一个“有序的子序列”，然后，逐一地，将“未排序”部分的元素，插入到这个有序子序列的、正确的位置上。
稳定性保障：当它，为一个新的元素，在“有序子序列”中，寻找插入位置时，其比较的逻辑通常是，从后往前，找到第一个“小于等于”该新元素的已有元素，然后，将新元素，插入到这个已有元素的“后面”。这个“等于”情况的处理，确保了，新插入的元素，永远不会，跑到那些“值相等、但位置更早”的、已存在元素的“前面”。
3. 归并排序 归并排序，是一种效率极高的、基于“分治”思想的稳定排序算法。其稳定性的保障，来自于其核心的“合并”操作。
合并操作：它需要将两个“已经有序”的子数组（例如，左数组和右数组），合并为一个新的、更大的有序数组。
稳定性保障的关键：在合并的过程中，当算法，同时，比较来自“左数组”的元素L和“右数组”的元素R时，如果发现 L 的值，等于 R 的值，那么，算法的实现，必须，且总是，优先地，将那个来自“左数组”（即，在原始序列中，位置更靠前）的元素L，先放入到新的数组中。这个看似微小的、在处理“相等”情况时的“偏向性”决策，正是归并排序，能够保持“稳定性”的“灵魂”所在。
三、不稳定排序的“颠覆者”们
这类算法，为了追求更高的、空间或时间上的效率，在其设计中，采用了“长距离”的、可能会“跨越”其他相等元素的“元素交换”操作，从而，破坏了原始的相对顺序。
1. 选择排序
核心机制：在每一次的遍历中，从“未排序”的部分，找到“最小”的那个元素，然后，将其，与“未排序”部分的“第一个”元素，进行一次“交换”。
不稳定的根源：这次“交换”，是一次“长距离”的跳跃。
- 示例：原始序列
[5A, 3, 5B, 2]，按数值排序。
第一轮：在整个序列中，找到最小值2。将其，与第一个元素5A，进行交换。
序列变为：[2, 3, 5B, 5A]
问题出现：在这次交换中，5A，被直接地，“跳跃”到了5B的“后面”。它们之间的原始相对顺序，已经被彻底颠覆。
2. 快速排序 快速排序，是所有排序算法中，平均性能最优、被应用最广，但其经典实现，却又是“不稳定”的、最具代表性的例子。
核心机制：分区。它通过一个“基准值”，将数组，分为“小于基准值”和“大于基准值”的两个子部分。
不稳定的根源：在其经典的“分区”实现中，通常，会使用两个“指针”，一个从左往右，一个从右往左，进行扫描。当左指针，找到一个大于基准值的元素，而右指针，找到一个小于基准值的元素时，就会将这两个“远距离”的元素，进行一次“交换”。正是这次“长距离”的交换，极有可能，会打乱相等元素的原始顺序。
- 示例：原始序列
[3, 5A, 2, 5B, 4]，选取4为基准值。
- 左指针从
3开始，右指针从5B开始。 - 左指针向右，找到
5A（大于4）。 - 右指针向左，找到
2（小于4）。 - 交换
5A和2。序列变为：[3, 2, 5A, 5B, 4]。 - 此时，
5A和5B的相对顺序，依然保持。 - 左指针继续，停在
5A。右指针继续，停在5A。分区结束。
- 换一个基准值：原始序列
[5A, 2, 5B, 4]，选取4为基准值。
- 左指针从
5A开始，右指针从5B开始。 - 左指针停在
5A（大于4）。 - 右指针停在
2（小于4）。 - 交换
5A和2。序列变为：[2, 5A, 5B, 4]。 - 问题，尚未出现。
- 左指针继续，停在
5A。右指针继续，停在5A。
更复杂的场景，更容易导致不稳定。尤其是在处理与基准值“相等”的元素时，不同的分区方案，其行为也不同，但大多数高效的实现，都不保证稳定性。
3. 堆排序 堆排序，通过构建一个“最大堆”或“最小堆”的数据结构，然后，反复地，将堆顶的“最值”元素，与堆底的元素，进行交换。这个“顶与底”的交换，同样，是一种“长距离”的交换，因此，它也是不稳定的。
四、在实践中“抉择”与“应用”
在理解了不同算法的“稳定性”之后，我们在实践中，该如何进行抉择？
1. 何时“必须”选择稳定排序？
多级排序场景：这是最核心、最不容出错的应用场景。例如，电商后台，需要对商品，先按“库存”排序，再按“销量”排序。
维持用户输入顺序：当集合的“原始顺序”本身，就隐含了某种“时间”或“重要性”的意义时。
2. 何时“可以”选择不稳定排序？
排序键唯一：如果要排序的“键”是唯一的（例如，按“身份证号”排序），那么，序列中，根本就不存在“相等”的元素，此时，“稳定性”这个概念，就变得毫无意义。
相对顺序不重要：在绝大多数的业务场景中，我们只关心最终的排序结果，而对那些值相同的元素的“谁先谁后”，并不关心。
追求极致性能：在某些对性能要求极高的、内存受限的场景下，快速排序，因其平均时间复杂度更优，且是“原地”排序（不需要额外的辅助空间），而常常，会比需要O(n)额外空间的归并排序，更受青睐。
3. 大多数语言内置排序的“秘密” 值得庆幸的是，为了避免开发者，掉入“稳定性”的陷阱，许多现代编程语言的“内置”排序函数，都已经被设计为了“稳定”的。
例如，Python的sort()和sorted()函数，其底层，采用的是一种名为“Timsort”的、高效的、稳定的混合排序算法。
Java中的Arrays.sort()对于对象数组的排序，和Collections.sort()，同样，都保证是稳定的。
因此，在大多数情况下，只要你使用的是语言提供的、高级的“内置”排序功能，你通常，都不必过分担心其稳定性问题。但当你，需要自己，去实现一个更底层的、或更定制化的**排序算法**时，对其“稳定性”的考量，就是必不可少的了。
五、在流程与工具中“管理”复杂性
将“稳定性”作为非功能性需求：对于一个面向用户的、提供复杂排序功能的需求，其“排序结果必须是稳定的”，应被作为一条明确的、可被测试的“非功能性需求”或“验收标准”，写入到需求文档中。
文档化与代码审查：在技术方案设计中，对于核心排序逻辑所采用的算法，及其“稳定性”的考量，应被清晰地文档化。在进行代码审查时（这个过程，可以在 PingCode 中，与合并请求进行联动），审查者，也应将“是否在需要稳定性的场景下，误用了不稳定的算法”，作为一个重要的检查点。
在通用项目中的体现：即便是在非研发的项目中，这个原则，也同样适用。例如，一个项目经理，在 Worktile 中，导出了一个包含了上百个任务的列表，并需要在电子表格软件中，对其进行“多列排序”。此时，他/她，必须清楚地，知道该软件的排序功能，是否是稳定的，以及，应该以怎样的“排序顺序”（例如，是先按“负责人”排，还是先按“截止日期”排），才能得到最终想要的、逻辑正确的视图。
常见问答 (FAQ)
Q1: “排序稳定性”和算法的“性能”有关系吗？
A1: 两者是独立的、描述算法不同维度的属性。“性能”（即时间/空间复杂度），描述的是算法运行的“快慢”和“资源消耗”。而“稳定性”，则描述的是算法在处理“相等元素”时的一种“行为特性”。存在既稳定又高效的算法（如归并排序），也存在不稳定但更高效的算法（如快速排序）。
Q2: 我如何知道我所用的编程语言内置的排序函数，是稳定还是不稳定的？
A2: 查阅该语言的官方文档，是唯一、最权威的方式。官方文档，会明确地，就其内置排序函数的“稳定性”，做出“承诺”或“不承诺”的说明。
Q3: “快速排序”既然不稳定，为什么还这么常用？
A3: 因为，在绝大多数的“平均”情况下，它的时间复杂度表现，是所有基于“比较”的排序算法中，最优的之一。同时，它是一个“原地”排序算法，不需要像“归并排序”那样，耗费大量的额外内存空间。在“稳定性”非必需，且追求综合性能的场景下，它依然是极佳的选择。
Q4: 是否可以将一个“不稳定”的排序算法，改造为“稳定”的？
A4: 可以。一种通用的改造方法是，在排序前，为每一个元素，都额外地，附加一个记录其“原始位置”的“索引”。然后，在进行排序比较时，如果两个元素的“主键”相等，就再去比较它们的“原始索引”，确保索引小的（即原始位置靠前的），永远被排在前面。但这会增加算法的“空间”和“时间”的复杂性。
文章包含AI辅助创作，作者：mayue，如若转载，请注明出处：https://docs.pingcode.com/baike/5214723
