JavaScript, ABAP 和 Scala 里的尾递归 (Tail Recursion)

2004 年 1 月 20 日，第一个公开版本的 Scala 发布。

Scala 是一种采用静态类型系统的编译型语言，具有很强的可扩展性(Scalability)，这也是其名称的由来。

Scala 设计初衷是集成面向对象编程和函数式编程的各种特性，运行于 JVM 平台上，并兼容已有的 Java 程序。

Jerry 没有在 SAP 标准产品开发中使用过 Scala，只是完成 2015 年公司一个内部培训布置的课程作业中，使用 Scala 在 Spark 上开发了一个最简单的 demo：统计海量英文图书里，计算出使用频率最高的十大单词。

Spark 是一个使用 Scala 编程语言实现的专为大规模数据处理而设计的快速通用的计算引擎。本文不会讨论 Spark，而是从 Scala 语言里，下图第 11 行的注解 @tailrec 谈起：尾递归(Tail Recursion).

每个程序员对递归的概念都耳熟能详，那什么是尾递归呢？

顾名思义，如果一个函数中递归形式的调用，出现在函数的末尾，且除了该递归调用外，不包含其他的运算操作，则我们称该递归函数是尾递归函数。

本文用阶乘算法来介绍尾递归的概念。

下图红色区域内是阶乘算法的常规递归实现，蓝色区域是阶乘算法的尾递归实现版本。在常规递归算法的末尾，第 8 行语句(绿色)，除了递归调用 factorial 函数外，还包含一个同 n 的乘法操作，所以整个函数 factorial 不能算作尾递归函数。

而尾递归版本中，第 14 行函数末尾(黄色)，仅仅包含函数本身的递归调用，所以整个函数 tailFactorial 是一个尾递归函数。

尾递归函数存在的意义是什么呢？要回答这个问题，我们可以先在单步调试模式下，观察常规递归函数的执行过程。

我们首先使用常规递归函数，计算 5 的阶乘。

输入参数 n 为 5，执行到第 7 行，5 的阶乘等于 5 乘以 4 的阶乘。单步调试进去，输入参数 n = 5, 进入第 7 行，准备执行 5 * factorial(4) .

注意观察下图的 Call Stack 列表，此时我们已经有两个 factorial 函数的调用栈帧了。

什么是栈帧？复习一下大学计算机原理学到的知识：在函数执行过程中，每一个函数调用都会把当前函数的调用信息和内部变量保存在栈里面，称为一个栈帧(Stack Frame).

其中下图序号为 1 的栈帧，保存了 n = 5 的计算上下文；序号为 2 的栈帧即当前最顶层的栈帧，保存了 n = 4 的计算上下文。

因为只有当 n = 1 时递归才会结束，而当前 n = 4，所以继续单步调试第 7 行：又生成了一个 n = 3 的栈帧：

n = 2：

终于我们来到了 n = 1 的上下文。看下图 Call Stack 里的栈帧列表，最顶层的栈帧代表当前 n = 1 的计算上下文。此时我们已经知道 n = 1 的阶乘结果如何计算了，即为 1 本身。

第 5 行代码返回 1 的阶乘计算结果 1，这行语句返回之后，当前序号为 5 的栈帧就会被销毁，即将回到下一层序号为 4 的栈帧去。

此时只剩 4 个栈帧了，最顶层代表 n = 2 的栈帧。因为现在 1 的阶乘结果已经出来了，所以 2 的阶乘结果也能计算了，为 2 乘以 1.

2 的阶乘返回后，现在只剩 3 个栈帧，最顶层为 n = 3 的计算上下文。3 的阶乘也能计算了，为 3 乘以前一个栈帧返回的计算结果，即 2 的阶乘结果，所以最后为 3 × 2 = 6. 如下图所示：

4 的阶乘计算，此时只剩两个栈帧：

5 的计算结果，回到最初最先被压到堆栈底部的 n = 5 的栈帧。计算完毕，5 的阶乘为 120.

是不是体现出了《数据结构》教科书上关于栈“先进后出”的工作原理？

下面再来看看用尾递归实现的阶乘。

下图第 20 行语句是以尾递归方式计算 5 的阶乘入口，调用尾递归函数 tailFactorial，注意函数的第二个输入参数 total，这个参数用于存储当前阶乘的计算结果。

这个尾递归函数的结束条件是，当第一个输入参数 n 为 1 时，就把第二个输入参数的值，作为阶乘运算的最终结果返回。第二个参数实际上存放的，是当前递归调用的阶乘计算结果。

当 n 大于 1 时，递归尚未满足退出条件，此时首先将 n 和当前的阶乘计算结果(变量 total)相乘，将乘积作为第二个输入参数，传递到下一层递归调用的栈帧中去。

下图是 tailFactorial 函数内部，即将进入第一轮递归调用的栈帧：

第一轮递归调用的栈帧内部，序号为 2.

注意，此时序号为 1 的栈帧已经完全不再需要了，因为我们继续进行递归调用的所需信息，都已经包含在第 16 行 tailFactorial 调用的两个输入参数里了，此时 n 为上一层递归调用传入的 5 - 1 = 4，total 为上一轮传入的 5 × 1 = 5. 进行下一轮递归调用，两个输入参数的值分别是 4 - 1 = 3 和 4 * 5 = 20.

进入第三层递归调用，此时输入参数 n = 3，total = 20，均为上一层调用传入。

注意，下图标号为 1 和 2 的两个栈帧，实际上不再需要了，因为要继续进行递归调用的所有输入信息，都已经存储在标号为 3 的栈帧里了：

n = 2， total = 60，同理，标号为 1，2，3 的栈帧都不再需要了。

n = 1，total = 120，终于计算结束了！这就是 5 的阶乘，如何通过尾递归的方式计算出来的全过程。

我们在标号为 5 的栈帧里得到了最终的结果，而此时虽然栈帧 1～4 还存在，但实际上已经毫无用处了。

因为按照尾递归版本的阶乘实现，每一轮阶乘的递归计算结果，已经通过第二个参数 total 保存了下来，因此没有必要再用一个完整的栈帧，去保存当前这轮递归计算的函数调用上下文了。这就引出了所谓“尾递归优化”的概念：

When a compiler detects a call that is tail recursive, it overwrites the current activation record instead of pushing a new one onto the stack. The compiler can do this because the recursive call is the last statement to be executed in the current activation; thus, there is nothing left to do in the activation when the call returns. Consequently, there is no reason to keep the current activation around. By replacing the current activation record instead of stacking another one on top of it, stack usage is greatly reduced, which leads to better performance in practice. Thus, we should make recursive functions tail recursive whenever we can.

https://www.oreilly.com/library/view/mastering-algorithms-with/1565924533/ch03s02.html

上述文字大意如下：

当(C 语言)编译器检测到尾递归调用时，并不会创建新的栈帧并压入栈中，而是用新的栈帧覆盖掉当前处于激活状态的栈帧。编译器之所以能够这样做，是因为尾递归函数里，递归调用是当前栈帧里最后一个需要执行的函数调用。被覆盖掉的栈帧本身毫无用处，不需要再保留。采用栈帧覆盖，而不是新建栈帧的方式，极大程度上减少了栈帧的个数，提高了递归函数的执行性能。因此，应该尽可能地去尝试使用尾递归方式实现递归函数。

一个实际的性能比较例子：计算 20 的阶乘，二者的性能有巨大差异：普通递归实现需要 10 毫秒，而尾递归实现仅仅需要不到 1 毫秒的时间。

注意：一个递归函数能否用尾递归方式实现，和它能否享受运行时的尾递归优化，二者不是一回事，后者需要编译器的支持。

应用开发人员通过 Scala 提供的 @tailrec 注解，告诉编译器，对注解修饰的方法进行尾递归优化：

如果优化失败，或者被修饰的方法根本就不是一个尾递归函数，则编译器报错：

could not optimize @tailrec annotated method fibonacci: it contains a recursive call not in tail position

用 ABAP 实现尾递归版本的阶乘运算：

至于 ABAP 编译器能否支持尾递归优化？我没有研究过，我只是觉得，尾递归优化并不能算是 ABAP 编译器必须实现的需求之一。

希望本文能帮助大家对尾递归优化这个概念有一个最基本的认识，感谢阅读。