这几天恰好和朋友谈起了递归，忽然发现不少朋友对于“尾递归”的概念比较模糊，网上搜索一番也没有发现讲解地完整详细的资料，于是写了这么一篇文章，权当一次互联网资料的补充。:P
递归与尾递归关于递归操作，相信大家都已经不陌生。简单地说，一个函数直接或间接地调用自身，是为直接或间接递归。例如，我们可以使用递归来计算一个单向链表的长度：
public class Node { public Node(int value, Node next) { this.Value = value; this.Next = next; } public int Value { get; private set; } public Node Next { get; private set; } }
编写一个递归的GetLength方法：
public static int GetLengthRecursively(Node head) { if (head == null) return 0; return GetLengthRecursively(head.Next) + 1; }
在调用时，GetLengthRecursively方法会不断调用自身，直至满足递归出口。对递归有些了解的朋友一定猜得到，如果单项链表十分长，那么上面这个方法就可能会遇到栈溢出，也就是抛出StackOverflowException。这是由于每个线程在执行代码时，都会分配一定尺寸的栈空间（Windows系统中为1M），每次方法调用时都会在栈里储存一定信息（如参数、局部变量、返回地址等等），这些信息再少也会占用一定空间，成千上万个此类空间累积起来，自然就超过线程的栈空间了。不过这个问题并非无解，我们只需把递归改成如下形式即可（在这篇文章里我们不考虑非递归的解法）：
public static int GetLengthTailRecursively(Node head, int acc) { if (head == null) return acc; return GetLengthTailRecursively(head.Next, acc + 1); }
GetLengthTailRecursively方法多了一个acc参数，acc的为accumulator（累加器）的缩写，它的功能是在递归调用时“积累”之前调用的结果，并将其传入下一次递归调用中——这就是GetLengthTailRecursively方法与GetLengthRecursively方法相比在递归方式上最大的区别：GetLengthRecursive方法在递归调用后还需要进行一次“+1”，而GetLengthTailRecursively的递归调用属于方法的最后一个操作。这就是所谓的“尾递归”。与普通递归相比，由于尾递归的调用处于方法的最后，因此方法之前所积累下的各种状态对于递归调用结果已经没有任何意义，因此完全可以把本次方法中留在堆栈中的数据完全清除，把空间让给最后的递归调用。这样的优化1便使得递归不会在调用堆栈上产生堆积，意味着即时是“无限”递归也不会让堆栈溢出。这便是尾递归的优势。
有些朋友可能已经想到了，尾递归的本质，其实是将递归方法中的需要的“所有状态”通过方法的参数传入下一次调用中。对于GetLengthTailRecursively方法，我们在调用时需要给出acc参数的初始值：
GetLengthTailRecursively(head, 0)
为了进一步熟悉尾递归的使用方式，我们再用著名的“菲波纳锲”数列作为一个例子。传统的递归方式如下：
public static int FibonacciRecursively(int n) { if (n < 2) return n; return FibonacciRecursively(n - 1) + FibonacciRecursively(n - 2); }
而改造成尾递归，我们则需要提供两个累加器：
public static int FibonacciTailRecursively(int n, int acc1, int acc2) { if (n == 0) return acc1; return FibonacciTailRecursively(n - 1, acc2, acc1 + acc2); }
于是在调用时，需要提供两个累加器的初始值：
FibonacciTailRecursively(10, 0, 1)尾递归与Continuation
Continuation，即为“完成某件事情”之后“还需要做的事情”。例如，在.NET中标准的APM调用方式，便是由BeginXXX方法和EndXXX方法构成，这其实便是一种Continuation：在完成了BeginXXX方法之后，还需要调用EndXXX方法。而这种做法，也可以体现在尾递归构造中。例如以下为阶乘方法的传统递归定义：
public static int FactorialRecursively(int n) { if (n == 0) return 1; return FactorialRecursively(n - 1) * n; }
显然，这不是一个尾递归的方式，当然我们轻易将其转换为之前提到的尾递归调用方式。不过我们现在把它这样“理解”：每次计算n的阶乘时，其实是“先获取n - 1的阶乘”之后再“与n相乘并返回”，于是我们的FactorialRecursively方法可以改造成：
public static int FactorialRecursively(int n) { return FactorialContinuation(n - 1, r => n * r); } // 6. FactorialContinuation(n, x => x) public static int FactorialContinuation(int n, Func<int, int> continuation) { ... }
FactorialContinuation方法的含义是“计算n的阶乘，并将结果传入continuation方法，并返回其调用结果”。于是，很容易得出，FactorialContinuation方法自身便是一个递归调用：
public static int FactorialContinuation(int n, Func<int, int> continuation) { return FactorialContinuation(n - 1, r => continuation(n * r)); }
FactorialContinuation方法的实现可以这样表述：“计算n的阶乘，并将结果传入continuation方法并返回”，也就是“计算n - 1的阶乘，并将结果与n相乘，再调用continuation方法”。为了实现“并将结果与n相乘，再调用continuation方法”这个逻辑，代码又构造了一个匿名方法，再次传入FactorialContinuation方法。当然，我们还需要为它补充递归的出口条件：
public static int FactorialContinuation(int n, Func<int, int> continuation) { if (n == 0) return continuation(1); return FactorialContinuation(n - 1, r => continuation(n * r)); }
很明显，FactorialContinuation实现了尾递归。如果要计算n的阶乘，我们需要如下调用FactorialContinuation方法，表示“计算10的阶乘，并将结果直接返回”：
FactorialContinuation(10, x => x)
再加深一下印象，大家是否能够理解以下计算“菲波纳锲”数列第n项值的写法？
public static int FibonacciContinuation(int n, Func<int, int> continuation) { if (n < 2) return continuation(n); return FibonacciContinuation(n - 1, r1 => FibonacciContinuation(n - 2, r2 => continuation(r1 + r2))); }
在函数式编程中，此类调用方式便形成了“Continuation Passing Style（CPS）”。由于C#的Lambda表达式能够轻松构成一个匿名方法，我们也可以在C#中实现这样的调用方式。您可能会想——汗，何必搞得这么复杂，计算阶乘和“菲波纳锲”数列不是一下子就能转换成尾递归形式的吗？不过，您试试看以下的例子呢？
对二叉树进行先序遍历（pre-order traversal）是典型的递归操作，假设有如下TreeNode类：
public class TreeNode { public TreeNode(int value, TreeNode left, TreeNode right) { this.Value = value; this.Left = left; this.Right = right; } public int Value { get; private set; } public TreeNode Left { get; private set; } public TreeNode Right { get; private set; } }
于是我们来传统的先序遍历一下：
public static void PreOrderTraversal(TreeNode root) { if (root == null) return; Console.WriteLine(root.Value); PreOrderTraversal(root.Left); PreOrderTraversal(root.Right); }
您能用“普通”的方式将它转换为尾递归调用吗？这里先后调用了两次PreOrderTraversal，这意味着必然有一次调用没法放在末尾。这时候便要利用到Continuation了：
public static void PreOrderTraversal(TreeNode root, Action<TreeNode> continuation) { if (root == null) { continuation(null); return; } Console.WriteLine(root.Value); PreOrderTraversal(root.Left, left => PreOrderTraversal(root.Right, right => continuation(right))); }
我们现在把每次递归调用都作为代码的最后一次操作，把接下来的操作使用Continuation包装起来，这样就实现了尾递归，避免了堆栈数据的堆积。可见，虽然使用Continuation是一个略有些“诡异”的使用方式，但是在某些时候它也是必不可少的使用技巧。
Continuation的改进看看刚才的先序遍历实现，您有没有发现一个有些奇怪的地方？
PreOrderTraversal(root.Left,
left => PreOrderTraversal(root.Right,
right => continuation(right)));
关于最后一步，我们构造了一个匿名函数作为第二次PreOrderTraversal调用的Continuation，但是其内部直接调用了continuation参数——那么我们为什么不直接把它交给第二次调用呢？如下：
PreOrderTraversal(root.Left,
left => PreOrderTraversal(root.Right, continuation));
我们使用Continuation实现了尾递归，其实是把原本应该分配在栈上的信息丢到了托管堆上。每个匿名方法其实都是托管堆上的对象，虽然说这种生存周期短的对象不会对内存资源方面造成多大问题，但是尽可能减少此类对象，对于性能肯定是有帮助的。这里再举一个更为明显的例子，求二叉树的大小（Size）：
public static int GetSize(TreeNode root, Func<int, int> continuation) { if (root == null) return continuation(0); return GetSize(root.Left, leftSize => GetSize(root.Right, rightSize => continuation(leftSize + rightSize + 1))); }
GetSize方法使用了Continuation，它的理解方法是“获取root的大小，再将结果传入continuation，并返回其调用结果”。我们可以将其进行改写，减少Continuation方法的构造次数：
public static int GetSize2(TreeNode root, int acc, Func<int, int> continuation) { if (root == null) return continuation(acc); return GetSize2(root.Left, acc, accLeftSize => GetSize2(root.Right, accLeftSize + 1, continuation)); }
GetSize2方法多了一个累加器参数，同时它的理解方式也有了变化：“将root的大小累加到acc上，再将结果传入continuation，并返回其调用结果”。也就是说GetSize2返回的其实是一个累加值，而并非是root参数的实际尺寸。当然，我们在调用时GetSize2时，只需将累加器置零便可：
GetSize2(root, 0, x => x)
不知您清楚了吗？
结束在命令式编程中，我们解决一些问题往往可以使用循环来代替递归，这样便不会因为数据规模造成堆栈溢出。但是在函数式编程中，要实现“循环”的唯一方法便是“递归”，因此尾递归和CPS对于函数式编程的意义非常重大。了解尾递归，对于编程思维也有很大帮助，因此大家不妨多加思考和练习，让这样的方式为自己所用。
注1：事实上，在C#中，即使您实现了尾递归，编译器（包括C#编译器及JIT）也不会进行优化，也就是说还是无法避免StackOverflowException。我会在不久之后单独讨论一下这方面问题。