Java和.NET：为什么默认情况下使用不同的排序算法？

只是想知道为什么，Java并且.NET Framework默认情况下使用不同的排序算法。

在Java中 ，默认情况下Array.Sort()使用合并排序算法，如Wikipedia.com所述：

在Java中，Arrays.sort（）方法根据数据类型使用合并排序或调整后的快速排序，当排序少于七个数组元素时，为了实现转换为插入排序的实现效率

在.NET Framework中， Array.Sort/List.Sort()使用“ 快速排序”作为默认排序算法（MSDN）：

List.Sort（）使用Array.Sort，后者使用QuickSort算法。此实现执行不稳定的排序；也就是说，如果两个元素相等，则可能不会保留其顺序。相反，稳定排序保留了元素相等的顺序。

通过查看出色的“算法比较”表，我们可以发现两种算法在最坏情况和内存使用情况方面的行为都大不相同：

这两个Java和.NET是企业解决方案发展的巨大框架，既有嵌入式开发平台。那么为什么他们默认使用不同的排序算法，有什么想法呢？

正如计算机本身具有确定性一样，计算机工程也不是一门精确的科学。给定相同问题域的两个人将进行分析，并开发出满足问题所有约束的两种不同解决方案。在一般情况下，根据经验确定其中哪一个“更好”可能很困难或不可能。

我的猜测是，.NET QuickSort位于MFC或Windows API中，并且可能继承自Windows的许多旧版本，在Windows的计算机中甚至都没有考虑过MergeSort的多用途优势。那天。（编辑：不是，尽管Microsoft开发人员一直以来都是QuickSort的狂热者，从MS-DOS以来的这种排序实现选择就证明了这一点）。

由于Java是从头开始设计为完全独立于平台的，因此Java无法使用任何特定于平台的实现，它采用了不同的方式。谁知道为什么MergeSort脱颖而出？我的大胆猜测是，与开发人员想出的其他实现相比，该实现赢得了某种性能竞争，或者就最佳情况和最坏情况而言，O（n）空间的MergeSort在纸上看起来都最好。 （MergeSort没有与QuickSort之类的元素选择相关的致命弱点，它的最佳情况是列表几乎排序，而这通常是QuickSort最糟糕的）。我怀疑最初考虑了多线程的好处，但是当前的实现很可能是多线程的。

两家不同公司的不同开发团队就其框架和组件的常用案例得出了不同的结论，并决定相应地实施。

本质上，每家公司都进行了分析，查看了他们的客户基础，并据此做出了不同的决定。

您不能期望不同的公司和团队使用不同的假设和原始数据进行分析得出相同的结论。

这个问题有点过时了，因为Java现在使用Timsort（从Java 7开始）

在提到的特定算法中：

• Quicksort在O（n ^ 2）的情况下具有不利的最坏情况性能，但更轻量/更少的内存消耗，因此在典型情况下可提供更好的性能。

• Mergesort保证了O（n log n）的最坏情况下的性能，但是会带来更多的开销和内存需求。它还是自动稳定的（即，以相同的顺序维护相等的元素）。

Java设计师总体上似乎更加保守/专注于“正确的事情”，因此毫不奇怪的是，他们从Mergesort中选择了Mergesort，因为它提供了更好的保证。

不确定Microsoft为什么选择Quicksort，也许他们选择了Quicksort，尽管这样做会使它们在某些微基准上看起来更好一些？