实际项目中怎么选排序算法：从面试题到工程落地

面试考排序算法是一回事，实际项目里用哪种是另一回事。很多人背完冒泡快排就完事了，但真到写代码的时候，Arrays.sort() 和 Collections.sort() 就够用了------那为什么还要学排序？因为理解了底层，才能在特殊场景做出正确选型。

打开 JDK 源码你会发现，Java 的排序不是一种算法包打天下：

为什么对象用归并不用快排？ 因为对象排序需要稳定性------两个相等的对象排完序后，它们的相对顺序不能变。快排是不稳定的，归并是稳定的，所以 JDK 选了归并（实际上是优化版的 TimSort）。

这个细节面试很爱问：为什么 Arrays.sort() 对基本类型和对象用不同算法？答案就是稳定性。

大部分业务场景，调 JDK 的 sort 就够了。但以下几种情况，你需要理解排序原理甚至自己实现：

1. 数据量极小：只有几个元素，快排的递归开销反而大，插入排序更合适。这也是为什么 JDK 在 TimSort 里，小数组会切换到插入排序。

2. 数据近乎有序：插入排序在近乎有序的数据上接近 O(n)，比快排快得多。如果业务场景里数据本来就大体有序（比如日志按时间排，只需要微调），插入排序是更好的选择。

3. 需要稳定排序：多字段排序时，先按 A 字段排，再按 B 字段排，如果不稳定，第二次排序会打乱第一次的结果。这时候必须用稳定排序（归并、插入、冒泡）。

4. 空间受限：嵌入式或内存极紧张的环境，归并的 O(n) 额外空间可能接受不了，这时候堆排序（O(1) 空间）更合适。

5. 数据分布均匀且范围已知：比如排序学生成绩（0-100），桶排序 O(n) 就搞定了，没必要 O(n log n)。

误区1：快排一定比冒泡快。

错。n=10 的时候，冒泡可能比快排还快------快排有递归开销和分区操作，数据量小的时候常数因子更大。

误区2：归并一定比快排慢。

错。归并是稳定的 O(n log n)，快排平均也是 O(n log n)，但快排最坏是 O(n²)。对性能要求严格的场景，归并的时间更可控。

误区3：桶排序总是最快。

错。桶排序只在数据分布均匀、范围已知时快。如果数据全堆在一个桶里，就退化成 O(n²) 了。

误区4：排序算法背下来就行。

不对。面试考的是你能不能根据场景选对算法，以及说出为什么。

遇到排序需求时，可以按这个思路判断：

大部分时候，你直接调 JDK 的 sort 就对了。但知道底层为什么这么选，面试和排查问题时都用得上。

排序算法不是为了让你手写，而是帮你建立"算法选型"的思维方式------面对一个问题，先分析数据特征，再选合适的算法，而不是上来就套最熟的那个。

更多排序算法的可视化演示和细节可以看原文------查看八种经典排序算法完整总结。

你在项目里手写过排序算法吗？什么场景？评论区交流。