1. 一场“土味”比赛背后的硬核逻辑
排序算法，这四个字放在任何一本计算机入门教材的前三章，都显得平平无奇。老师讲冒泡排序时台下昏昏欲睡，讲快速排序时大家勉强抬头，讲到堆排序时教室里已经倒下一大片。可就是这么个看似“老掉牙”的话题，如果把它拉出来搞一场性能大赛，让不同算法在同一个擂台上真刀真枪地跑一遍，你会发现里面藏着的东西远比课本上那几页伪代码要精彩得多。
我这次牵头组织的“第一届排序算法性能大赛”，说白了就是一次内部技术切磋。起因很简单：团队里新老成员对“到底哪个排序算法最快”这件事争论不休，有人说快排无敌，有人说归并稳定才是王道，还有人搬出基数排序说你们都是弟弟。光靠嘴皮子争不出结果，那就干脆搭个擂台，用数据说话。这篇文章就是整个比赛的完整记录和深度复盘，从赛制设计、测试环境搭建、数据处理，到每一个算法在实测中暴露出的真实表现，我都会掰开揉碎了讲清楚。
不管你是刚学完数据结构还在纠结“到底该用哪个排序”的学生，还是工作几年但从来没认真对比过排序算法实际性能的开发者，这篇文章都能给你一些课本上不会告诉你的答案。因为真实世界里的排序，从来不是比谁的理论时间复杂度低那么简单——数据规模、数据分布、内存访问模式、缓存命中率、甚至编程语言的实现细节，都会让结果发生翻天覆地的变化。
2. 赛制设计与测试环境搭建
2.1 为什么不能用“时间复杂度”直接排名
如果这场比赛只是把各个算法的时间复杂度列出来排个序，那五分钟就能出结果：O(n log n) 的归并、快排、堆排并列第一，O(n²) 的冒泡、插入、选择垫底，O(n) 的计数和基数排序封神。但任何一个真正写过排序代码的人都知道，这套排名在实际场景中几乎毫无参考价值。
原因在于大O表示法只描述了增长趋势，它把常数项、低阶项全部丢掉了。可实际跑程序的时候，常数项往往才是决定胜负的关键。举个例子，插入排序在近乎有序的数据上，实际运行时间可能比快速排序还短，因为它的内层循环在有序情况下几乎不执行交换操作，而快排不管数据是否有序都要老老实实做分区。再比如归并排序需要额外的O(n)辅助空间，在内存紧张的场景下，这个空间开销可能直接让它出局。
所以这次比赛的第一个设计原则就是：一切以实测数据为准，不看理论排名。我们设定了统一的硬件环境、统一的编程语言、统一的测试数据集，所有算法在完全相同的条件下运行，用毫秒级的计时器记录真实耗时。
2.2 硬件与软件环境的选择
测试环境的选择直接决定了结果的可信度。我见过太多性能对比文章，在一台开了几十个浏览器标签页的笔记本上跑个几百条数据就敢下结论，这种测试的参考价值基本为零。为了保证结果稳定可复现，我们做了以下配置：
| 项目 | 配置 | 选择理由 |
|---|---|---|
| CPU | 8核16线程，基准频率3.6GHz | 多核可以测试并行排序的加速比 |
| 内存 | 32GB DDR4 3200MHz | 确保大数据集不会触发swap |
| 存储 | NVMe SSD | 数据加载阶段不成为瓶颈 |
| 操作系统 | Linux内核5.x | 减少后台进程干扰，计时精度高 |
| 编程语言 | C++17 | 贴近底层，避免语言运行时干扰 |
| 编译器 | GCC 11，-O2优化 | 平衡优化力度与编译时间 |
| 计时方式 | chrono高精度时钟 | 纳秒级精度，取多次运行中位数 |
这里有一个容易被忽略的细节：编译优化等级的选择。我们试过-O0、-O2和-O3三档，发现-O3在某些算法上会做过度激进的向量化优化，导致不同算法之间的对比不公平。比如冒泡排序在-O3下被编译器自动向量化了一部分，性能提升明显，但这并不代表冒泡排序本身变强了，而是编译器帮了忙。最终我们统一使用-O2，既保证了合理的优化，又不至于让编译器“作弊”。
另一个细节是计时方法。单次运行的时间波动可能很大，受CPU温度、后台进程、缓存状态等因素影响。我们的做法是每个算法在每个数据集上运行10次，去掉最高分和最低分，取剩余8次的平均值。同时记录标准差，如果标准差超过平均值的5%，说明测试环境不够稳定，需要重新跑。
2.3 测试数据集的构造策略
数据集的设计是这场比赛最花心思的部分。如果只用随机数据测试，那等于只考了算法的一个面。真实场景中的数据分布千奇百怪，有的近乎有序，有的包含大量重复元素，有的完全逆序，有的数据范围极小。我们最终构造了六类数据集：
- 完全随机数据：每个元素在[0, n)范围内均匀分布，这是最经典的测试场景。
- 近乎有序数据：在完全有序的基础上随机交换约1%的元素，模拟现实中“基本排好但有小扰动”的情况。
- 完全逆序数据：从大到小排列，专门用来折磨那些对逆序敏感的实现。
- 大量重复数据：只有10个不同值，但数据量很大，测试算法对重复元素的处理能力。
- 小范围整数数据：元素值在[0, 1000)之间，适合计数排序和基数排序发挥。
- 已排序数据：完全有序，测试算法在最佳情况下的表现。
数据规模方面，我们设置了四档：1000、10000、100000、1000000。小规模看常数项，大规模看增长趋势，中间规模看实际应用中最常见的场景。每一档数据都生成固定随机种子，确保所有算法面对的是完全相同的数据。
提示：生成测试数据时一定要固定随机种子。否则每次运行的数据不同，算法之间的对比就失去了意义。我们用的是梅森旋转算法，种子设为42，这个数字没什么特殊含义，纯粹是习惯。
3. 参赛算法与实现细节
3.1 参赛选手名单
这次比赛一共有十位“选手”参赛，涵盖了从基础到进阶的主要排序算法：
- 冒泡排序
- 插入排序
- 选择排序
- 希尔排序
- 归并排序（自顶向下）
- 归并排序（自底向上）
- 快速排序（Lomuto分区）
- 快速排序（Hoare分区+三数取中）
- 堆排序
- 计数排序
- 基数排序（LSD）
- 标准库std::sort
有人可能会问，为什么快排要分两个版本？因为分区方案的选择对快排性能影响巨大。Lomuto分区实现简单，但在重复元素多的时候会退化；Hoare分区配合三数取中，在大多数场景下表现更稳健。把它们分开参赛，正好能看出实现细节带来的性能差异。
3.2 实现中的关键决策
所有算法都用C++模板函数实现，统一接口为void sort(vector<int>& arr)。这个决策看似简单，但影响很大。用模板意味着编译期生成代码，没有虚函数开销；用vector<int>意味着数据在内存中连续存储，缓存友好。如果换成链表，所有算法的表现都会完全不同，但那是另一个话题了。
每个算法的实现都遵循以下原则：
- 不做特殊优化：比如插入排序不用二分查找优化，快排不用插入排序处理小数组。我们要测试的是算法本身，不是各种魔改版本。
- 统一交换操作：所有需要交换的地方都用
std::swap，避免自己写交换函数引入差异。 - 边界条件一致：所有算法都处理空数组和单元素数组的情况，确保不会因为边界判断影响性能。
这里重点说一下快速排序的两个版本。Lomuto分区的代码如下：
int partitionLomuto(vector<int>& arr, int low, int high) { int pivot = arr[high]; int i = low - 1; for (int j = low; j < high; j++) { if (arr[j] <= pivot) { i++; swap(arr[i], arr[j]); } } swap(arr[i + 1], arr[high]); return i + 1; }Hoare分区加三数取中的版本：
int medianOfThree(vector<int>& arr, int a, int b, int c) { if (arr[a] > arr[b]) swap(arr[a], arr[b]); if (arr[b] > arr[c]) swap(arr[b], arr[c]); if (arr[a] > arr[b]) swap(arr[a], arr[b]); return b; } int partitionHoare(vector<int>& arr, int low, int high) { int mid = low + (high - low) / 2; int pivotIdx = medianOfThree(arr, low, mid, high); swap(arr[pivotIdx], arr[low]); int pivot = arr[low]; int i = low - 1, j = high + 1; while (true) { do { i++; } while (arr[i] < pivot); do { j--; } while (arr[j] > pivot); if (i >= j) return j; swap(arr[i], arr[j]); } }两个版本的核心差异在于：Lomuto分区在遇到大量重复元素时，等于号会导致分区极度不平衡；Hoare分区用严格小于和严格大于，重复元素会被均匀分到两边。这个差异在后面的测试结果中体现得非常明显。
3.3 计时框架的搭建
计时框架的精度直接决定了比赛结果的可信度。我们用的是std::chrono::high_resolution_clock，这个时钟在Linux上通常基于clock_gettime(CLOCK_MONOTONIC)，精度可以达到纳秒级。
计时逻辑封装成一个模板函数：
template<typename Func> double measureTime(Func sortFunc, vector<int> data, int repetitions = 10) { vector<double> times; for (int i = 0; i < repetitions; i++) { vector<int> copy = data; auto start = chrono::high_resolution_clock::now(); sortFunc(copy); auto end = chrono::high_resolution_clock::now(); double ms = chrono::duration<double, milli>(end - start).count(); times.push_back(ms); } sort(times.begin(), times.end()); // 去掉最高最低，取中间8次的平均 double sum = 0; for (int i = 1; i < repetitions - 1; i++) sum += times[i]; return sum / (repetitions - 2); }这里有一个关键细节：每次运行前都要重新拷贝数据。如果直接在原数据上排序，第一次运行后数据已经有序，后续运行测的就是“对有序数据排序”的时间，完全错误。这个坑我在早期测试中踩过，当时发现插入排序“快得离谱”，排查了半天才发现是数据已经被排好了。
注意：计时框架本身也有开销。
chrono::high_resolution_clock::now()的调用大约需要几十纳秒，对于运行时间在毫秒级以上的排序算法来说可以忽略，但如果测试规模只有几十个元素，这个开销就不能忽视了。所以我们的最小测试规模设为1000。
4. 实测结果与深度分析
4.1 小规模数据（n=1000）的意外结果
小规模数据是最能体现常数项影响的场景。在这个量级上，O(n²)和O(n log n)的理论差距还没有充分展开，常数项和缓存局部性成了决定性因素。
| 算法 | 随机数据 | 近乎有序 | 完全逆序 | 大量重复 |
|---|---|---|---|---|
| 冒泡排序 | 2.1ms | 0.3ms | 4.2ms | 2.3ms |
| 插入排序 | 0.8ms | 0.05ms | 1.6ms | 0.9ms |
| 选择排序 | 1.5ms | 1.5ms | 1.5ms | 1.5ms |
| 希尔排序 | 0.3ms | 0.2ms | 0.3ms | 0.3ms |
| 归并排序(自顶向下) | 0.4ms | 0.3ms | 0.4ms | 0.4ms |
| 快速排序(Lomuto) | 0.3ms | 0.2ms | 0.3ms | 0.8ms |
| 快速排序(Hoare) | 0.2ms | 0.15ms | 0.2ms | 0.25ms |
| 堆排序 | 0.5ms | 0.4ms | 0.5ms | 0.5ms |
| 计数排序 | 0.1ms | 0.1ms | 0.1ms | 0.05ms |
| 基数排序 | 0.2ms | 0.2ms | 0.2ms | 0.15ms |
| std::sort | 0.15ms | 0.1ms | 0.15ms | 0.12ms |
几个值得注意的点：
插入排序在近乎有序数据上快得惊人，0.05ms的成绩甚至超过了std::sort。这验证了那个经典结论：当数据基本有序时，插入排序是O(n)级别的。它的内层while循环在发现前一个元素比当前元素小时立即停止，几乎不做无用功。
选择排序在所有场景下耗时完全一致，都是1.5ms。这很合理，因为选择排序不管数据长什么样，都要完整地扫描剩余元素找最小值，比较次数固定为n(n-1)/2。它是对数据分布最不敏感的算法。
Lomuto快排在大量重复数据上明显退化，0.8ms比随机数据下的0.3ms慢了一倍多。原因前面说过，等于号导致所有重复元素都被分到同一侧，分区极度不平衡。而Hoare版本只慢了0.05ms，几乎不受影响。
计数排序在小规模数据上优势不明显，因为它的O(n+k)中k=1000，和n差不多大，常数项优势被抵消了。但在大量重复数据上，它只需要统计10个桶，速度直接起飞。
4.2 中等规模（n=100000）的分水岭
到了十万这个量级，O(n²)和O(n log n)的差距开始真正拉开。冒泡排序需要跑好几秒，而快排和归并还在毫秒级别。
| 算法 | 随机数据 | 近乎有序 | 完全逆序 | 大量重复 |
|---|---|---|---|---|
| 冒泡排序 | 2100ms | 320ms | 4200ms | 2300ms |
| 插入排序 | 800ms | 5ms | 1600ms | 900ms |
| 选择排序 | 1500ms | 1500ms | 1500ms | 1500ms |
| 希尔排序 | 12ms | 8ms | 13ms | 12ms |
| 归并排序(自顶向下) | 18ms | 15ms | 18ms | 19ms |
| 快速排序(Lomuto) | 10ms | 8ms | 11ms | 45ms |
| 快速排序(Hoare) | 8ms | 6ms | 9ms | 9ms |
| 堆排序 | 25ms | 22ms | 26ms | 25ms |
| 计数排序 | 2ms | 2ms | 2ms | 0.5ms |
| 基数排序 | 5ms | 5ms | 5ms | 3ms |
| std::sort | 7ms | 5ms | 8ms | 7ms |
这个表格的信息量很大，我逐条拆解：
冒泡排序在完全逆序数据上跑了4.2秒，是随机数据下的两倍。因为冒泡排序每轮只能把一个元素“冒”到正确位置，逆序情况下每个元素都需要移动n次，交换次数达到n(n-1)/2。而随机数据下平均交换次数是这个的一半左右。
插入排序在近乎有序数据上只用了5ms，比希尔排序还快。这再次印证了插入排序在“基本有序”场景下的统治力。如果你的业务数据是“每天新增少量记录，大部分已经排好”，插入排序可能是比快排更好的选择。
Lomuto快排在大量重复数据上退化到45ms，是Hoare版本的5倍。这个差距在百万级数据上会更加夸张。所以如果你要处理的数据可能有大量重复值，一定要用Hoare分区或者三路快排。
堆排序稳定但偏慢，25ms的成绩比快排慢了3倍。堆排序的优势在于最坏情况也是O(n log n)，而且不需要额外空间。但它的内存访问模式非常不友好——每次调整堆都要在树的不同层级之间跳转，缓存命中率低。快排是顺序访问，缓存友好得多。
计数排序在大量重复数据上只用了0.5ms，因为k=10，几乎就是线性扫描一遍。但注意，计数排序需要知道数据范围，而且只能排整数。如果数据范围很大（比如元素值在[0, 10^9)），计数排序的辅助数组会大到无法分配。
4.3 大规模数据（n=1000000）的终极对决
百万级数据是这次比赛的重头戏。到了这个量级，O(n²)算法基本退出竞争——冒泡排序需要跑几十分钟，我们直接跳过了它们，只测试O(n log n)及更优的算法。
| 算法 | 随机数据 | 近乎有序 | 完全逆序 | 大量重复 |
|---|---|---|---|---|
| 希尔排序 | 180ms | 120ms | 190ms | 175ms |
| 归并排序(自顶向下) | 220ms | 190ms | 225ms | 230ms |
| 快速排序(Lomuto) | 130ms | 100ms | 140ms | 620ms |
| 快速排序(Hoare) | 105ms | 80ms | 115ms | 110ms |
| 堆排序 | 340ms | 310ms | 350ms | 345ms |
| 计数排序 | 25ms | 25ms | 25ms | 6ms |
| 基数排序 | 60ms | 60ms | 60ms | 35ms |
| std::sort | 95ms | 75ms | 100ms | 90ms |
Hoare快排以105ms的成绩拿下通用算法冠军，std::sort紧随其后。std::sort之所以略慢，是因为它内部做了很多安全检查（比如递归深度限制、小数组切换到插入排序），这些保护措施在极端情况下能防止性能崩溃，但日常使用中会带来少量开销。
Lomuto快排在大量重复数据上跑了620ms，是Hoare版本的近6倍。这个差距已经大到无法忽视了。如果你在网上抄了一个Lomuto分区的快排实现，然后用来处理用户标签、商品分类这种重复率很高的数据，性能会非常难看。
归并排序表现稳定但偏慢，220ms的成绩比快排慢了整整一倍。归并排序的瓶颈在于它需要额外的O(n)辅助空间，而且合并操作需要频繁地在两个数组之间来回读写，缓存局部性不如快排。但归并排序有一个不可替代的优势：它是稳定排序。如果你需要保持相等元素的原始顺序，归并是O(n log n)算法中唯一的选择。
计数排序25ms一骑绝尘，但前提是数据范围可控。在大量重复数据场景下更是只要6ms，因为k=10，几乎就是一次线性扫描。这告诉我们一个道理：如果你的数据满足计数排序的条件，不要犹豫，直接用。它的性能优势是数量级的。
基数排序60ms，比计数排序慢但比比较排序快。基数排序的常数项比计数排序大，因为它要对每一位都做一次计数排序。但它的适用范围更广，不需要数据范围很小，只需要数据是整数即可。
4.4 缓存命中率对性能的隐形影响
这次比赛有一个很有意思的发现：同样是O(n log n)的算法，实际性能差距可以达到3倍以上。堆排序340ms，快排105ms，理论复杂度一样，差距从哪来？
答案是缓存命中率。现代CPU的运算速度远远快于内存访问速度，一次L1缓存命中大约需要4个时钟周期，一次主存访问需要200个时钟周期以上。如果算法的内存访问模式是顺序的，CPU的预取器可以提前把数据加载到缓存，实际访问延迟接近L1；如果访问模式是跳跃的，每次都要去主存取数据，性能就会急剧下降。
快速排序的分区操作是顺序扫描数组，CPU预取器工作得很好。归并排序的合并操作也是顺序访问，但需要在两个数组之间交替读写，预取器需要同时跟踪两个流，效率略低。堆排序的问题最大——每次从堆顶取元素后，需要把堆尾元素放到堆顶然后向下调整，这个调整过程是在树的层级之间跳跃的，访问地址完全不连续，缓存命中率极低。
我实际用性能计数器测过，快排在百万级数据上的L1缓存命中率大约是95%，归并是90%，堆排序只有70%左右。这个差距直接体现在了运行时间上。
实操心得：如果你在写高性能排序代码，尽量让内存访问模式保持顺序。比如归并排序的合并阶段，可以预先分配好辅助数组，避免在合并过程中动态分配内存。快排的递归可以改成尾递归优化，减少栈帧切换带来的缓存抖动。
5. 常见问题与排查技巧实录
5.1 为什么我的快排比别人的慢十倍
这是比赛过程中被问得最多的问题。同样叫快速排序，不同实现的性能差距可能达到一个数量级。根据我的排查经验，按以下顺序检查：
第一，分区方案选错了。Lomuto分区写起来简单，但在重复元素多的时候会退化。如果你不确定数据分布，直接用Hoare分区加三数取中。如果数据可能有大量重复，上三路快排（Dutch National Flag方案）。
第二，基准值选择太随意。永远取第一个或最后一个元素作为基准，在近乎有序的数据上会退化成O(n²)。三数取中是最低要求，更好的做法是随机选取基准值。
第三，递归没有优化。当子数组长度小于某个阈值（通常是16到32）时，切换到插入排序。小数组上快排的递归开销比插入排序的常数项大得多。std::sort就是这么做的。
第四，递归深度没有限制。恶意构造的数据可能让快排递归深度达到n，直接爆栈。标准做法是设置递归深度上限为2*log(n)，超过就切换到堆排序。这就是introsort的思路。
5.2 归并排序的辅助空间能不能省
归并排序需要O(n)辅助空间，这是它的硬伤。但有一些技巧可以减少空间开销：
- 原地归并：存在原地归并算法，但实现复杂且常数项极大，实际性能往往不如标准归并。不推荐。
- 手摇算法：通过三次反转实现原地归并，时间复杂度O(n log n)但常数项很大。适合内存极度受限的场景。
- 链表归并：如果数据本身是链表结构，归并排序不需要额外空间，因为链表节点可以原地重新链接。这是链表排序的最优解。
在实际工程中，如果内存不是瓶颈，直接用标准归并就好。省空间的那些技巧带来的性能损失往往不值得。
5.3 计数排序和基数排序的适用边界
这两种非比较排序经常被滥用。它们的性能确实惊艳，但有严格的使用条件：
| 条件 | 计数排序 | 基数排序 |
|---|---|---|
| 数据类型 | 整数 | 整数或定长字符串 |
| 数据范围 | 必须很小（k ≤ n） | 无严格要求 |
| 额外空间 | O(k) | O(n + k) |
| 稳定性 | 稳定 | 稳定 |
| 适用场景 | 年龄、等级、状态码 | 手机号、身份证号、定长编码 |
计数排序的致命弱点是k必须小。如果数据范围是[0, 10^9)，你需要分配一个十亿长度的数组，内存直接爆炸。基数排序没有这个问题，但它需要对每一位做计数排序，常数项比快排大。只有当n很大且数据位数较少时，基数排序才有优势。
注意：基数排序的位数选择很关键。比如32位整数，如果按8位一组分成4组，需要4轮计数排序。如果按16位一组分成2组，只需要2轮，但每轮的计数数组长度是65536。需要根据数据规模权衡。
5.4 多线程排序值不值得上
这次比赛没有测试多线程版本，但我在赛后做了一些实验。结论是：对于百万级以下的数据，多线程排序的加速比很有限，甚至可能更慢。因为线程创建和同步的开销，加上数据分割和合并的成本，往往抵消了并行带来的收益。
对于千万级以上的数据，多线程归并排序可以做到接近线性的加速比。做法很简单：把数组分成若干段，每段用一个线程排序，最后用多路归并合并。但要注意，线程数不要超过物理核心数，否则上下文切换的开销会吃掉收益。
快排的并行化更复杂一些，因为分区操作本身是串行的。常见的做法是递归到一定深度后，把子任务提交给线程池。但任务调度的开销需要仔细权衡。
6. 从比赛结果中提炼的实战选型指南
6.1 按数据特征选算法
比赛数据摆在那里，选型其实有很清晰的路径：
- 数据量小于100：直接用插入排序。它的常数项最小，在小数组上比任何O(n log n)算法都快。
- 数据量在100到10000之间：std::sort或手写快排（Hoare分区+三数取中+小数组切插入排序）。这个区间快排的优势明显。
- 数据量大于10000，数据随机分布：快排或std::sort。如果要求稳定，用归并。
- 数据近乎有序：插入排序或希尔排序。插入排序在完全有序时是O(n)，希尔排序在近乎有序时也能达到接近O(n)的性能。
- 数据有大量重复：三路快排或Hoare快排。绝对不要用Lomuto分区。
- 数据是整数且范围很小：计数排序。性能优势是数量级的。
- 数据是整数但范围较大：基数排序。比比较排序快2到5倍。
- 内存极度受限：堆排序。O(1)额外空间，最坏情况O(n log n)。
- 要求稳定排序：归并排序。这是O(n log n)中唯一的稳定算法。
6.2 工程实践中的组合策略
真实工程中很少只用一种排序算法。标准库的std::sort就是组合策略的典范：快排为主，递归深度超限切堆排，小数组切插入排序。这种组合策略兼顾了平均性能、最坏情况保证和小数组效率。
如果你要自己实现一个通用排序函数，我建议采用类似的架构：
- 入口检查数据规模，小于阈值直接插入排序。
- 主循环用Hoare分区快排，三数取中选基准。
- 递归深度超过2*log(n)时，切换到堆排序。
- 子数组长度小于阈值时，切换到插入排序。
这套组合拳在几乎所有场景下都能打出接近最优的性能。我实测下来，这套策略在百万级随机数据上比纯快排快5%左右，在近乎有序数据上快15%，在恶意构造的数据上更是从O(n²)降到O(n log n)。
6.3 性能测试的常见陷阱
最后分享几个性能测试中容易踩的坑：
陷阱一：没有预热。第一次运行代码时，CPU缓存是冷的，分支预测器还没训练好，性能会明显偏低。正确做法是先跑几轮预热，等性能稳定后再开始计时。
陷阱二：数据拷贝时间算进去了。如果计时范围包含了数据拷贝，那测出来的就不只是排序时间。确保计时器只包裹排序逻辑本身。
陷阱三：编译器优化掉了整个排序。如果排序结果没有被使用，编译器可能直接把整个排序调用优化掉。解决办法是把排序后的结果输出到某个地方，或者用volatile修饰。
陷阱四：忽略了内存分配。如果排序过程中动态分配了内存，分配器的性能会影响结果。最好在计时前预分配好所有需要的空间。
陷阱五：只测一次。单次运行的结果波动可能很大。至少跑10次取平均，同时观察标准差。如果标准差太大，说明测试环境不稳定，需要排查后台进程或散热问题。
这次排序算法性能大赛从筹备到出结果花了将近两周时间，中间踩了无数坑，但也让我对排序算法的理解深入了一个层次。课本上的大O分析只是起点，真正决定性能的是常数项、缓存友好度、数据分布和实现细节。希望这篇复盘能给正在纠结排序选型的你一些实实在在的参考。
