理解递归的本质：递归与栈

递归的基本思想

所谓递归，就是有去有回。

递归的基本思想，是把规模较大的一个问题，分解成规模较小的多个子问题去解决，而每一个子问题又可以继续拆分成多个更小的子问题。

最重要的一点就是假设子问题已经解决了，现在要基于已经解决的子问题来解决当前问题；或者说，必须先解决子问题，再基于子问题来解决当前问题。

或者可以这么理解：递归解决的是有依赖顺序关系的多个问题。

我们假设一个抽象问题有两个时间点要素：开始处理，结束处理。

那么递归处理的顺序就是，先开始处理的问题，最后才能结束处理。

假设如下问题的依赖关系：

【A】----依赖---->【B】----依赖---->【C】

我们的终极目的是要解决问题A，

那么三个问题的处理顺序如下：

开始处理问题A；

由于A依赖B，因此开始处理问题B；

由于B依赖C，开始处理问题C；

结束处理问题C；

结束处理问题B；

结束处理问题A。

从函数调用看广义递归

对于软件来说，函数的调用关系就是一个广义递归的过程，如下，

func_A()

{

func_B();

}

func_B()

{

func_C();

}

func_C()

{

/

}

调用函数A；

调用函数B；

调用函数C；

函数C返回；

函数B返回；

函数A返回；

狭义递归函数

有一种特例，就是处理问题A/B/C的方法是一样的，这就是产生了狭义的“递归函数“，即函数内又调用函数自身。

从上述分析看，递归对问题的处理顺序，是遵循了先入后出（也就是先开始的问题最后结束）的规律。

先入后出？栈！

没错，广义递归问题的处理，需要用栈来解决。经典的例子就是函数调用，就是依靠栈来实现的。

递归函数的非递归化

现在再来深入分析一下狭义的递归函数（也就是函数调用自身）。

我们知道递归函数存在的最大问题是，当递归次数足够大时，会导致函数栈溢出而死机，函数栈的大小一般是一个固定值，对于linux来说一般默认是8M。

因此，编程老司机会教导我们，不得用递归函数！但递归函数的代码实现实在是简洁啊，不让用？臣妾做不到啊！

那么问题来了，所有递归函数都能非递归化吗？答案是肯定的。

本质上讲，对于同一个问题，如果必然要用广义递归的方案来处理，那么狭义递归函数只不过是其中的一种实现方式，如果放弃狭义递归函数的话，我们不得不借助一个额外的数据结构：栈。

如此看来，无论如何都要用到栈，只不过要么让编译器来维护一个栈（函数栈），要么让程序狗来维护一个栈（数据栈）。

这两个栈的区别如下：

	函数栈	数据栈
位置	进程的stack区	进程的heap区
大小限制	小（8M？）	能分配到很大
每个栈“元素”所需空间	比较大，因为要存储函数上下文	可以设计到很小，比如只存储一个指针
栈开销	大	可以做的很小
代码简易程度/可维护性	简洁易读	相对更复杂

注：函数栈开销是一个绝对值，但也算是一个“相对“概念，一个非量化的理性分析是，内部逻辑越简单的函数，栈开销的影响越大，因为函数的出入栈指令占整个函数体指令的比重较大。

很多情况下，代码的易维护性是一个比性能开销更加重要的因素，因此，只要实际应用中不会造成函数栈溢出，我个人是更建议采用递归函数法的。

举例说明：二叉树的非递归遍历

非递归算法的递归化

既然递归算法可以用数据栈来进行非递归化，那么借助数据栈而实现的非递归算法，理论上也可以被递归化。也就是说，两者是可逆的，桥梁就是栈。