数据结构与算法之美-递归-极客时间笔记

递归操作是一种高效、简洁的编码技巧，在代码中的表现就是方法调用自己本身。

可以采用递归的问题需要满足三个条件：

1. 一个问题可以分解为几个子问题的解；
2. 这个问题与分解之后的子问题，除了数据规模不同，求解思路完全一样；
3. 存在递归终止条件，即问题分解到底层后可以终止再层层回溯。

写递归代码的关键就是找到如何将大问题分解为小问题的规律，并且基于此写出递推公式，然后再推敲终止条件，最后将递推公式和终止条件翻译成代码。人脑对于一层层嵌套的循环往往很难想明白，不要让自己陷入一层层的递归中，把注意力集中在每一层的分解上，先假设子问题已经得到解决，那么通过子问题如何来解决最终问题（这就是推导公式的过程）。在解决大方向公式后，再考虑终止条件，也就是这个递归公式在向内“递”到什么时候失灵，需要我们来设定最里层的求解值。然后从最里层开始往外“归”，验证终止条件是否已经足够。

递归代码要警惕堆栈溢。函数调用会使用栈来保存临时变量。每调用一个函数，都会将临时变量封装为栈帧压入内存栈，等函数执行完成返回时，才出栈。系统栈或者虚拟机栈空间一般都不大。如果递归求解的数据规模很大，调用层次很深，一直压入栈，就会有堆栈溢出的风险。所以递归方法的适应场景不能涉及太深，可以直接在调用递归函数太深时直接抛出错误。

递归代码要警惕重复计算。从下图中，我们可以直观地看到，f(3) 就被计算了很多次，这就是重复计算问题。解决办法就是将求解过的f(x)保存起来，在再次需要求解的时候先进行查询，没有查询到结果的情况下才计算。

除了上面说到的两点，函数调用也是存在时间消耗和空间消耗的。所以说递归有利有弊，利是递归代码的表达力很强，写起来非常简洁。虽然我们能够通过迭代循环的方式改写递归，但这样就类似之前说的写递归公式的思维陷阱，想不明白所有情况的话很难写清楚。在开发过程中，我们要根据实际情况来选择是否需要用递归的方式来实现。