数据结构-05 |递归

时间：2020-06-28 20:25:24 阅读：44 评论：0 收藏：0 [点我收藏+]

1. 递归Recursion

1.1 概念

生活中就有很多用到递归的例子。

周末带着女朋友去电影院看电影，女朋友问，咱们现在坐在第几排啊？电影院里面太黑了，看不清

于是你就问前面一排的人他是第几排，你想只要在他的数字上加一，就知道自己在哪一排了。但是，前面的人也不知道，所以他也问他前面的人。就这样一排一排往前问，直到问到第一排的人，说我在第一排，然后再这样一排一排再把数字传回来。直到你前面的人告诉你他在哪一排，于是你就知道答案了。

这就是一个非常标准的递归求解问题的分解过程，去的过程叫“递”，回来的过程叫“归”。

基本上，所有的递归问题都可以用递推公式来表示。刚刚这个例子，用递推公式表示：

f(n)=f(n-1)+1 其中，f(1)=1
f(n) 表示你想知道自己在哪一排，f(n-1) 表示前面一排所在的排数，f(1)=1 表示第一排的人知道自己在第一排。有了这个递推公式，我们就可以很轻松地将它改为递归代码，如下：
int f(int n) {
  if (n == 1) return 1;
  return f(n-1) + 1;
}

Recursion

递归 — 循环通过函数体来进行的循环（函数自己调自己）

递归
1. 从前有个山，
2. 山里有个庙，
3. 庙里有个和尚讲故事：--> 1

技术图片

递归类似盗梦空间中不断的层层递进再层层回来的这种结构；

　　①向下进入到不同梦境中；向上又回到原来一层；（一层层的上，一层层的回来，对称性）

　　②通过声音同步回到上一层；（同步的关系即用参数来进行，函数不同层之间的传递变量）

　　 ③每一层的环境和周围的人都是一份拷贝，主角等几个人穿越不同层级的梦境（发生和携带变化）

1.2 递归需要满足的三个条件

刚刚这个例子是非常典型的递归，那究竟什么样的问题可以用递归来解决呢？只要同时满足以下三个条件，就可以用递归来解决。

1. 一个问题的解可以分解为几个子问题的解

何为子问题？子问题就是数据规模更小的问题。比如，前面讲的电影院的例子，你要知道，“自己在哪一排”的问题，可以分解为“前一排的人在哪一排”这样一个子问题。

2. 这个问题与分解之后的子问题，除了数据规模不同，求解思路完全一样

你求解“自己在哪一排”的思路，和前面一排人求解“自己在哪一排”的思路，是一模一样的。

3. 存在递归终止条件

把问题分解为子问题，把子问题再分解为子子问题，一层一层分解下去，不能存在无限循环，这就需要有终止条件。第一排的人不需要再继续询问任何人，就知道自己在哪一排，也就是 f(1)=1，这就是递归的终止条件。

1.3 递归代码

写递归代码最关键的是写出递推公式，找到终止条件，剩下将递推公式转化为代码就很简单了。

写递归代码的关键就是找到如何将大问题分解为小问题的规律，并且基于此写出递推公式，然后再推敲终止条件，最后将递推公式和终止条件翻译成代码。

人脑几乎没办法把整个“递”和“归”的过程一步一步都想清楚。计算机擅长做重复的事情，所以递归正和它的胃口。而我们人脑更喜欢平铺直叙的思维方式。当我们看到递归时，我们总想把递归平铺展开，脑子里就会循环，一层一层往下调，然后再一层一层返回，试图想搞清楚计算机每一步都是怎么执行的，这样就很容易被绕进去。

如果一个问题 A 可以分解为若干子问题 B、C、D，你可以假设子问题 B、C、D 已经解决，在此基础上思考如何解决问题 A。而且，你只需要思考问题 A 与子问题 B、C、D 两层之间的关系即可，不需要一层一层往下思考子问题与子子问题，子子问题与子子子问题之间的关系。屏蔽掉递归细节，这样子理解起来就简单多了。

因此，编写递归代码的关键是，只要遇到递归，我们就把它抽象成一个递推公式，不用想一层层的调用关系，不要试图用人脑去分解递归的每个步骤。

递归模板代码：

public void recur(int level, int param) {
        //1. terminator 递归终结条件
　　if (level > Max_LEVEL) {
       //process result
　　　 return;
   }
       //2. process current logic 处理当前逻辑
　　process(level, param);
       //3. drill down  下探到下一层
　　recur(level: level + 1, newParam);
       //4. restore current level status if needed 清理当前层
}

1.4 递归的问题

1.4.1 递归代码要警惕堆栈溢出

堆栈溢出会造成系统性崩溃。为什么递归代码容易造成堆栈溢出呢？该如何预防堆栈溢出呢？

在使用“栈”时，函数调用会使用栈来保存临时变量。每调用一个函数，都会将临时变量封装为栈帧压入内存栈，等函数执行完成返回时，才出栈。系统栈或者虚拟机栈空间一般都不大。如果递归求解的数据规模很大，调用层次很深，一直压入栈，就会有堆栈溢出的风险。

比如电影院的例子，如果我们将系统栈或者 JVM 堆栈大小设置为 1KB，在求解 f(19999) 时便会出现如下堆栈报错：

Exception in thread "main" java.lang.StackOverflowError

那么，如何避免出现堆栈溢出呢？

可以通过在代码中限制递归调用的最大深度的方式来解决这个问题。递归调用超过一定深度（比如 1000）之后，我们就不继续往下再递归了，直接返回报错。

还是电影院那个例子，我们可以改造成下面这样子，就可以避免堆栈溢出了。下边是伪代码：

// 全局变量，表示递归的深度。
int depth = 0;
int f(int n) {
    ++depth；
    if (depth > 1000) throw exception;
    if (n == 1) return 1;
  return f(n-1) + 1;
}

但这种做法并不能完全解决问题，因为最大允许的递归深度跟当前线程剩余的栈空间大小有关，事先无法计算。如果实时计算，代码过于复杂，就会影响代码的可读性。所以，如果最大深度比较小，比如 10、50，就可以用这种方法，否则这种方法并不是很实用。

1.4.2 递归代码要警惕重复计算

从图中，我们可以直观地看到，想要计算 f(5)，需要先计算 f(4) 和 f(3)，而计算 f(4) 还需要计算 f(3)，因此，f(3) 就被计算了很多次，这就是重复计算问题。

为了避免重复计算，我们可以通过一个数据结构（比如散列表）来保存已经求解过的 f(k)。当递归调用到 f(k) 时，先看下是否已经求解过了。如果是，则直接从散列表中取值返回，不需要重复计算，这样就能避免重复计算的问题了。

public int f(int n) {
    if (n == 1) return 1;
    if (n == 2) return 2;
// hasSolvedList 可以理解成一个 Map，key 是 n，value 是 f(n)
    if (hasSolvedList.containsKey(n)) {
    return hasSolvedList.get(n);
  }
    int ret = f(n-1) + f(n-2);
    hasSolvedList.put(n, ret);
    return ret;
}

除了堆栈溢出、重复计算这两个常见的问题。递归代码还有如 函数调用耗时多、空间复杂度高等问题。

在时间效率上，递归代码里多了很多函数调用，当这些函数调用的数量较大时，就会积聚成一个可观的时间成本。在空间复杂度上，因为递归调用一次就会在内存栈中保存一次现场数据，所以在分析递归代码空间复杂度时，需要额外考虑这部分的开销，比如我们前面讲到的电影院递归代码，空间复杂度并不是 O(1)，而是 O(n)。

1.5 递归代码改写为迭代循环

递归有利有弊，利是递归代码的表达力很强，写起来非常简洁；而弊就是空间复杂度高、有堆栈溢出的风险、存在重复计算、过多的函数调用会耗时较多等问题。所以，在开发过程中，我们要根据实际情况来选择是否需要用递归的方式来实现。

那我们是否可以把递归代码改写为非递归代码呢？比如刚才那个电影院的例子，我们抛开场景，只看 f(x) =f(x-1)+1 这个递推公式。

int f(int n) {
    int ret = 1;
    for (int i = 2; i <= n; ++i) {
      ret = ret + 1;
  }
    return ret;
}

int f(int n) {
    if (n == 1) return 1;
    if (n == 2) return 2;
    int ret = 0;
    int pre = 2;
    int prepre = 1;
  for (int i = 3; i <= n; ++i) {
    ret = pre + prepre;
    prepre = pre;
    pre = ret;
    }
    return ret;
}

所有的递归代码是否都可以改为这种迭代循环的非递归写法呢？笼统地讲，是的。递归本身就是借助栈来实现的，只不过我们使用的栈是系统或者虚拟机本身提供的，我们没有感知罢了。如果我们自己在内存堆上实现栈，手动模拟入栈、出栈过程，这样任何递归代码都可以改写成看上去不是递归代码的样子。

但是这种思路实际上是将递归改为了“手动”递归，本质并没有变，而且也并没有解决前面讲到的某些问题，徒增了实现的复杂度。

递归的应用

推荐注册返佣金的这个功能，

用户 A 推荐用户 B 来注册，用户 B 又推荐了用户 C 来注册。A -> B -> C ，用户 C 的“最终推荐人”为用户 A，用户 B 的“最终推荐人”也为用户 A，而用户 A 没有“最终推荐人”。

一般来说，我们会通过数据库来记录这种推荐关系。在数据库表中，我们可以记录两行数据，其中 actor_id 表示用户 id，referrer_id 表示推荐人 id。

技术图片

给定一个用户 ID，如何查找这个用户的“最终推荐人”？

long findRootReferrerId(long actorId) {
    Long referrerId = select referrer_id from [table] where actor_id = actorId;
    if (referrerId == null) return actorId;
    return findRootReferrerId(referrerId);
}