Timsort事件告诉我们……

排序是计算机工作者最熟悉的问题，数据结构课程介绍了一批排序算法。但是，每个算法都有弱项，权衡利弊，传统上实际使用最多的还是快速排序或其变形。实际上，快速排序有三大缺点：糟糕的最坏时间复杂性（O(n^2)），不具有稳定性，且不具有适应性（或说具有反适应性，被处理数组越接近排序状态时排序越慢）。受到偏爱的原因就是它在实际使用中“比较快”，快就是好。

现在情况有些变化，因为出现了Timsort。这是一种正在崛起、使用越来越广泛的排序算法。有人说该算法源自Peter McIlroy的想法和设计，但实际上McIlroy只是对归并和插入技术的结合做了些理论分析，并没有给出实际算法。Tim Peters在2002年为Python开发基础设施时结合使用归并和插入，并辅以另外一些技术手段，实现了后来被人称为Timsort的排序算法（程序）。该算法的基本工作过程大致是：

1.  扫描数组，确定其中的单调上升段和严格单调下降段，将严格下降段反转；
2. 定义最小基本片段长度，短于此的单调片段通过插入排序集中为长于此的段；
3. 反复归并一些相邻片段，过程中避免归并长度相差很大的片段，直至整个排序完成，所用分段选择策略可以保证O(n log n)时间复杂性。
   

在实际算法中，上面几项工作交织在一起进行，还做了许多调整和优化。算法的详情见Python文档（https://hg.python.org/cpython/file/tip/Objects/listsort.txt）。

Timsort避免了快速排序的几个重要缺点：其最坏情况时间复杂性是O(n log n)（没有快速排序的极端慢速情况），具有稳定性和适应性。最重要的是，通过各种数据试验，结论是Timsort的性能极好，很多试验中它的表现优于快速排序。由于这些情况，Java从SE7开始用Timsort取代了原排序算法（这一替代并非向后兼容，可能导致已有程序崩溃），Android系统平台和GNU Octave也用Timsort作为标准排序函数。这一趋势还可能继续，会有更多的语言和系统采用（或改用）这种排序算法作为基础设施。

故事说到这里都是好消息，现在应该转到本文的主题了。

事情要从欧洲的几个形式化方法研究者说起。经过多年工作，这些研究者开发了一种专用于Java程序（实际上是JML程序，在普通Java程序里加入JML规范）的形式化验证工具KeY，并用KeY系统成功验证了一些程序，包括计数排序和基数排序等。为进一步检验KeY的价值，他们找到Java标准库的Timsort，觉得这是一个很合适的验证对象：它比较复杂，规模不是太大，而且正在作为Java语言的基础设施被广泛使用，其重要性毋庸置疑。研究者试着用KeY证明Timpsort的正确性，工作一段无法成功而转去检查原因，通过仔细分析发现Timpsort的基本归并循环不能维持证明中定义的不变式。进一步深入分析代码发现了一个错误。实际情况是，对一些形式比较特殊的数组，Java的Timsort排序函数必定崩溃。研究者检查了Python的原实现，发现也存在同样错误。他们提出了新的不变式，按这一不变式修改程序就能消除错误。详情见http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/。

这里简单说明错误的一些细节。前面说过，在实际算法里，单调分段的识别、构造（通过反转或插入排序）和归并交织进行，因此需要确定每步应归并的相邻分段。Tim Peters通过分析提出了一套选择准则（归并循环的不变式）。归并过程中需要用一个栈缓存待处理分段，显然，栈的最大可能项数与被排序数组的规模有关。为保证效率，Tim Peters根据循环不变式推算出栈的长度（类似于斐波那契序列的逆函数），在开始排序前分配空间。可惜的是，由于认识的局限性，Timsort执行中可能打破上述不变式，出现更多片段需要缓存的情况。当数组中数据具有某些特殊分布情况时，运行中会出现栈溢出（数组越界）。特别的，当时的程序在数组长度为65536时就可能出现栈溢出。Java移植代码直接采用原代码的计算规则，对同样的数组也会出问题。

有趣的是，Java SE7发布后有用户报告了这个错误，指出对某些数组会出现溢出（当时栈容量为20，被排序数组包含65536个元素），而且可重现。开发人员不知道如何修复，就把这时的栈容量扩充到24。后又有报告说对包含67108864个元素的数组，当时设置为40个元素的栈也可能溢出。开发人员再扩容，又发现对1073741824个元素的数组可能出现溢出情况。这次开发人员做了些分析，认为“85 is ridiculously large enough, good for an array with 2**64elements”，认为可以把栈长度设为85。错误报告到Python开发团队，Tim Peters认为这是个“低”优先级错误，硬件不支持出错情况的数组规模。后来其他开发者还是根据KeY研究者的建议改了程序，也修改了栈分配方法，把栈长度简单设置为85。实际上，该程序对更大的数组还是可能出错，但他们不想管了。

故事讲完了，它给我们提供了什么值得注意的启示呢？

首先，似乎很难把Timsort出现的问题归结为测试不充分。请设想一下，在不知错误的情况下，测试人员有可能做出能触发错误的用例吗？无论是人工设计还是随机生成，都不大可能造出正好能触发错误的65536个元素的数组。目前研究界和业界正在研究测试用例自动生成方法，都是设法根据代码拼凑出触发错误的用例，有关技术不可能解决这里的问题。实际上，对各种通用的底层基础模块和库模块，很难构造出足够丰富的测试用例集。

另一个事实也很有趣：用户报告Timsort有错后，开发人员完全无能力弄清错误的原因，也不知道应该怎样修改程序。实际中这种情况绝不罕见。接到错误报告后，有多少维护人员能找到错误的真正根源，从根本上修正错误？实际维护人员常常没有这种能力，只能简单地打补丁，就像在Timsort里把20改为24。进一步说，他们对修改的潜在影响也毫无预期。正因为此，我们看到复杂软件系统里的错误层出不穷，永无止境。可以想象，在我们深度依赖的各种基础设施中还隐藏着大量致命错误，不知道什么时候爆发出来。

Timsort的基本思想不太复杂，不难根据有关想法写出一个朴素实现，保证其正确性（能正确排序）、时间效率要求（O(n log n)）和存储安全性（不出现数组越界等）。但这种朴素实现需要O(n) 栈空间。Tim Peters希望做出一个高度优化的程序，最重要的一个优化目标就是处理实际数据时能少用存储。所做优化导致完成不同工作的代码高度纠缠，也使Timsort主循环变得很复杂，需要维持一个很复杂的不变式。从Timsort的代码和说明中可以看到实现者做的优化，其中有许多很值得称道的想法。但也正是这些优化导致了隐藏很深的错误，这一事实再次印证了Knuth的名言：“不成熟的优化是万恶之源”。然而，为了底层模块和关键代码的效率，软件人员常常需要做这种代码调优。Timsort的事实再次说明，用一组测试用例来检查优化版本与原版本等价，这种常用技术并不可靠。

Tim Peters是国际知名的软件开发专家，经验非常丰富。从有关Timsort的文档中可以看到其工作态度之慎重，思考之认真和缜密。然而，即使如此有经验并下了如此功夫，也不能避免犯错误。专家们尚且如此，更不用说只有一般经验和专业水平的程序员了。随着程序变得越来越复杂，人工思考和推导的完整性和可信程度也会快速衰败。

Timsort的设计和实现也表现出循环不变式的重要作用。没有循环不变式的指导，人们根本不可能写出这样复杂的算法。Tim Peters充分理解这一点，他通过细致分析设计出主归并循环的“不变式”，并仔细论证。然而，如此认真工作还是没有避免错误。这个事实说明，开发经验、深入分析和认真工作，仍不足以支持复杂程序的开发活动。作为故事的另一面，我们也看到，计算机辅助的形式化分析和推导确实有效。KeY的研究者们并没有那么仔细地研究Timsort算法，他们只是按部就班地在Timsort代码里加入形式化规范，在辅助证明系统的帮助下做严格推导，就发现了错误并确定了解决方法。

Timsort的故事告诉我们，目前软件开发活动的技术基础依然非常脆弱。特别是对复杂的效率要求高的基础设施、底层软件和最常用的库，非常缺乏保证质量的有效技术手段和工具。即使是经过长期运行检验、维护、排除错误的软件，难免还存在各种隐藏很深的错误。这些年不时爆出的事件也说明了这种说法不是危言耸听。解决基础软件、底层软件和常用库的脆弱性问题，需要采用各种技术手段和其他手段。形式化方法、严格的推理和验证已经在这方面表现出重要的作用和价值，应该引起软件工作者的重视。