JavaScript中的递归、PTC、TCO和STC

近来，好像大家都对函数式编程及其概念非常感兴趣。可是，很多人不谈递归，特别是不谈PTC（Proper Tail Call，适当的尾调用）。而这才是编写清晰简洁代码，同时又不导致栈溢出的关键。

本文将通过图示的方法讨论递归，讨论什么是PTC、TCO（Tail Call Optimization，尾调用优化）、STC（Syntactic Tail Call，语法级尾调用），以及它们的区别、原理，还会讨论主流JavaScript引擎对它们的实现。

递归

递归出现在某个问题的解决方案依赖于对其别的实例应用同样的解决方案之时。

比如，4的factorial（阶乘）可以定义为3的factorial乘以4。

这意味着一个数的阶乘可以通过它自己来定义：

简言之，在函数调用自身时，我们说就用到了递归。

理解递归

说到理解递归，我比较喜欢想象从首次执行衍生出多个执行分支，然后这些分支的执行结果再“冒泡”回到根调用。

以前面计算阶乘为例，第一次调用派生出多个调用，直到派生出本身存在定义的调用为止（具体来说，就是到调用0的阶乘为止，因为根据定义0的阶乘为1）。然后，这个定义的结果立即返回（冒泡），以便基于这个结果执行另一个操作并再次返回值。之后这个过程重复进行，直到把最终结果返回给“根”调用。

如果用图示方式可视化地展示以5为参数调用factorial函数，那么可以这样表示：

与编译器理论相比较，这个过程非常像使用上下文无关语法取得句子，直至遇到终点值。

乍一看还挺抽象，那我们就换一种方式来说明一下，这次以计算N个数的Fibonnacci Sequence（斐波纳契数列）为例。

这是Fibonacci函数的代码：

简单地说，每次调用Fibonacci函数都会派生两次新调用，新调用同样调用自身，直到参数变成一个小于2的数（因为此时的斐波纳契数列从1和1相加开始，结果为2）。

在参数小于2时，直接返回结果给上级调用，然后上级调用再逐级将结果冒泡返回给根调用。

如下图所示，调用fibonacci(4)会派生多次调用，直到调用能够直接返回结果（“既定方案”），在这里就是Fibonacci数列的前两个数：1（fibonacci(1)）和1（fibonacci(0)）。

由于每次递归调用都依赖于另外两次递归调用（除非参数小于2直接返回既定结果），因此我们从叶节点（1）开始返回值，然后对两次递归调用的结果求和，再把结果返回给上级调用。

如上面的例子所示，递归有线性递归和分支递归之分。线性递归，就是递归调用只有一个分支，就像计算阶乘那样。分支递归，就是递归调用不止一个分支，像计算斐波纳契数列那样。

说到递归，主要应该考虑两点：

定义退出条件，也就是自身即结果的原子级定义（也叫“既定结果”）。定义算法的哪个部分是可递归的

定义了退出条件后，就可以轻松确定什么情况下函数还要再调用自己，什么情况下可以直接使用现成的结果。

如果想了解更多关于递归的实践和有趣应用，请参考树和图相关算法的工作原理。

递归与调用栈

通常，在使用递归的时候，一般都会产生一个函数调用栈，其中每个函数都需要使用前一次自我调用的结果。

为说明使用递归时的调用栈是什么样的，我们以简单的factorial函数作例子。

以下是它的代码：

接下来，我们调用它看看3的阶乘。

通过前面的例子我们知道，3的阶乘要计算factorial(2)、factorial(1)和factorial(0)并将它们的结果相乘。这意味着，要计算3的阶乘，需要额外调用3次factorial函数。

以上每次调用都会把一个新的栈帧推到调用栈上，而所有调用都进栈后的结果大致如下：

现在，我们添加对console.trace的调用，以便调用factorial函数时在调用栈中看到当前的栈帧。

更改后的代码应该是这样的：

下面我们就来运行代码，分析打印出的每一段调用栈信息。

这是第一段：

看到了吧，第一个调用栈只包含对factorial函数的第一次调用，也就是factorial(3)。接下来就有意思了：

这次我们在上一次调用基础上又调用了factorial函数。这个调用是factorial(2)。

这是调用factorial(1)时的栈：

我们看到，这在之前调用的基础上又增加了一次调用。

最后是调用factorial(0)时的调用栈：

正像我在本节开始时说的一样，调用factorial(3)需要进一步调用factorial(2)、factorial(1)和factorial(0)。这就是factorial函数在调用栈中现身4次的原因。

适当的尾调用（PTC）

ES6出来后应该会实现适当的尾调用，但是由于我将在本文后面解释的原因，所有主要的JS引擎目前都没有实现。

适当的尾调用可以避免递归调用时的栈膨胀。不过，为了做到适当的尾调用，我们首先得有一个尾调用。

那什么是尾调用？

尾调用是执行时不会造成栈膨胀的函数。尾调用是执行return之前要做的最后一个操作，而这个被调用函数的返回值由调用它的函数返回。调用函数不能是生成器函数。

为了演示适当的尾调用如何起作用，我们需要重构factorial函数，实现尾递归：

好了，现在这个函数要做的最后一件事就是返回调用自身的结果，这就是尾调用。

大家可能注意到了，这次我们给函数传递了两个参数：一个是我们想要计算下一个阶乘的数值（n - 1），一个是累积的总数，即n * total。

现在，我们不一定需要（像前面例子中那样）先取得派生调用的叶节点了。因为我们有了求解当前问题所需的所有值（累积的值，以及下一次应该计算的阶乘）。

我们来分析一下，为什么这个函数可以在不依赖多次递归调用的情况下完成计算。

以下是调用factorial(4)的过程。

在栈顶部压入一个对factorial的调用。因为不是0（既定情况），那么我们知道下一次要计算的值（）和当前累积值（4 * total）。再次调用factorial，它会得到完成计算所需的所有数据：要计算的下一个阶乘和累积的总数。至此，不再需要之前的栈帧了，可以把它弹出，只添加新的调用factorial(3, 4)。这次调用同样大于0，于是需要计算下一个数的阶乘，同时将累积值（）与当前值（）相乘。至此（又）不再需要上一次调用了，可以把它弹出，再次调用factorial并传入和12。再次更新累积值为24，同时计算的阶乘。前一帧又从栈中被删除，我们又用乘以24（总数），并计算的阶乘。最后，的阶乘返回了累积的总数，也就是24（就是4的阶乘）。

简单说吧，这就是整个过程：

现在，不需要在栈中保留n个帧，而只要保留1个即可。因为后续调用并不依赖之前的调用。结果就是新factorial函数的内存复杂变由O(N)变成了O(1)。

在Node中使用适当的尾调用

给上面的函数添加一行console.trace调用，并且调用factorial(3)以便看到栈中的调用情况：

你会发现，虽然这个函数已经是尾递归的了，但栈中仍然保存了多次对factorial函数的调用：

为了在Node中使用适当的尾调用，必须在JS文件顶部添加'use strict'以启用strict mode，然后以--harmony_tailcalls标记来运行。

为了让以上标记能改进factorial函数，我们的脚本应该是这样的：

下面这样运行：

再次运行后，得到如下栈跟踪信息：

如你所见，每次栈中保存的对factorial的调用只有一个了。因为每次调用这个函数后，之前的调用帧就没用了。

因此说到如何创建尾调用函数，关键就在于传递下一次调用所需的全部“状态”，这样才能达到删除下一帧的目的。有时候在一个函数里可能无法做到这一点，此时可以考虑利用嵌套函数实现尾递归。

要记住，适当的尾调用不一定会让代码跑得更快。实际上，多数情况下，有了它反而会更慢。

然而，使用适当的尾调用除了可以节省调用栈的内存占用，还会由于在局部声明的对象使运行递归函数占用的内存更少。由于下一次递归调用不必使用当前帧中的任何变量，因此垃圾收集器就可以把当前帧中的所有对象销毁了。但在“非尾递归”函数中，每调用一次递归函数，都要分配一次内存。毕竟所有帧在最后一次递归调用（即返回“既定情况”的调用）返回前，都必须保存在帧里。

尾调用优化（TCO）

与适当的尾调用不同，尾调用优化的目的则是提升尾递归函数的性能，让它们跑得更快。

尾调用优化是编译器使用的一种技术，它使用jumps把递归调用转换成一个循环。

我们已经知道了尾递归函数的执行过程，那么在此基础上解释尾调用优化也就简单了。

仍然以前面的factorial函数为例，我们来看看假如我们的JavaScript引擎启用了尾调用优化会怎么样。

以下是起始代码：

既然以上代码在退出条件（“既定情况”）满足前会重复执行，那我们何不把重复的代码装到一个标签里，直接来回跳转，从而避免重复调用自己呢？好，实现以上想法的代码如下：

这说明尾调用优化与实现适当的尾调用不是一回事！

实现适当的尾调用及尾调用优化的缺点

在前面的例子中我们看到，适当的尾调用意味着不会在栈里“保存”调用函数的历史。结果查看栈追踪信息就很难定位到问题，因为它并不包含所有调用信息，怎么知道是哪次调用导致出错？

前面提到的文章中涉及的console.trace语句和Error.stack属性都会因此受影响。

对此，可以通过在开发环境中使用“影子栈”（Shadow Stack）来解决。

影子栈就是“备份栈”。虽然正常的栈在适当的尾调用下不会保存所有帧，但所有调用都可推入这个“影子栈”，以便利用它进行调试，同时还不会污染执行栈。

然而，可以想见，目前这方面还没有可靠易用的工具。而且，这样一来又要在另一个地方占用更多内存以保存所有帧（开发环境下应该不是问题）。

还有，对于实现尾调用优化的代码，影子栈也解决不了Error.stack属性的问题。因为此时将使用goto语句，不会再向栈追踪信息中添加任何帧信息。这意味着假如有错误对象被创建，那么产生这个错误的函数可能并不在栈里。因为我们是直接在函数内跳转，而不是像递归那样重复调用函数。