整理自極客時間-資料結構與演算法之美。原文內容更完整具體，且有音訊。購買地址：

如何理解遞迴

資料結構和演算法有兩個最難理解的知識點，一個是動態規劃，另一個就是遞迴。

遞迴是一種應用非常廣泛的演算法（或者程式設計技巧）。之後我們要講的很多資料結構和演算法的編碼實現都要用到遞迴，比如 DFS 深度優先搜尋、前中後序二叉樹遍歷等等。所以，搞懂遞迴非常重要，否則，後面複雜一些的資料結構和演算法學起來就會比較吃力。

咱們生活中就有很多用到遞迴的例子，如：

週末你帶著女朋友去電影院看電影，女朋友問你，咱們現在坐在第幾排啊？電影院裡面太黑了，看不清，沒法數，現在你怎麼辦？

於是遞迴就開始排上用場了。你就問前面一排的人他是第幾排，你想只要在他的數字上加一，就知道自己在哪一排了。但是，前面的人也看不清啊，所以他也問他前面的人。就這樣一排一排往前問，直到問到第一排的人，說我在第一排，然後再這樣一排一排再把數字傳回來。直到你前面的人告訴你他在哪一排，於是你就知道答案了。

這就是一個非常標準的遞迴求解問題的分解過程，去的過程叫“遞”，回來的過程叫“歸”。基本上，所有的遞迴問題都可以用遞推公式來表示。剛剛這個生活中的例子，我們用遞推公式將它表示出來就是這樣的：

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;
}

遞迴需要滿足的三個條件

剛剛這個例子是非常典型的遞迴，那究竟什麼樣的問題可以用遞迴來解決呢？只要同時滿足以下三個條件，就可以用遞迴來解決。

1. 一個問題的解可以分解為幾個子問題的解

何為子問題？子問題就是資料規模更小的問題。比如，前面講的電影院的例子，你要知道，“自己在哪一排”的問題，可以分解為“前一排的人在哪一排”這樣一個子問題。

2. 這個問題與分解之後的子問題，除了資料規模不同，求解思路完全一樣

比如電影院那個例子，你求解“自己在哪一排”的思路，和前面一排人求解“自己在哪一排”的思路，是一模一樣的。

3. 存在遞迴終止條件

把問題分解為子問題，把子問題再分解為子子問題，一層一層分解下去，不能存在無限迴圈，這就需要有終止條件。

還是電影院的例子，第一排的人不需要再繼續詢問任何人，就知道自己在哪一排，也就是 f(1)=1，這就是遞迴的終止條件。

如何編寫遞迴程式碼

剛剛鋪墊了這麼多，現在我們來看，如何來寫遞迴程式碼？我個人覺得，寫遞迴程式碼最關鍵的是寫出遞推公式，找到終止條件，剩下將遞推公式轉化為程式碼就很簡單了。

牛客網跳臺階刷題連線：假如這裡有 n 個臺階，每次你可以跨 1 個臺階或者 2 個臺階，請問走這 n 個臺階有多少種走法？如果有 7 個臺階，你可以 2，2，2，1 這樣子上去，也可以 1，2，1，1，2 這樣子上去，總之走法有很多，那如何用程式設計求得總共有多少種走法呢？

我們仔細想下，實際上，可以根據第一步的走法把所有走法分為兩類，第一類是第一步走了 1 個臺階，另一類是第一步走了 2 個臺階。所以 n 個臺階的走法就等於先走 1 階後，n-1 個臺階的走法 加上先走 2 階後，n-2 個臺階的走法。用公式表示就是：

f(n) = f(n-1)+f(n-2)

有了遞推公式，遞迴程式碼基本上就完成了一半。我們再來看下終止條件。當有一個臺階時，我們不需要再繼續遞迴，就只有一種走法。所以 f(1)=1。這個遞迴終止條件足夠嗎？我們可以用 n=2，n=3 這樣比較小的數試驗一下。

n=2 時，f(2)=f(1)+f(0)，如果遞迴終止條件只有一個 f(1)=1，那 f(2) 就無法求解了。所以除了 f(1)=1 這一個遞迴終止條件外，還要有 f(0)=1，表示走 0 個臺階有一種走法，不過這樣子看起來就不符合正常的邏輯思維了。所以，我們可以把 f(2)=2 作為一種終止條件，表示走 2 個臺階，有兩種走法，一步走完或者分兩步來走。

所以，遞迴終止條件就是 f(1)=1，f(2)=2。這個時候，你可以再拿 n=3，n=4 來驗證一下，這個終止條件是否足夠並且正確。

我們把遞迴終止條件和剛剛得到的遞推公式放到一起就是這樣的：

f(1) = 1;
f(2) = 2;
f(n) = f(n-1)+f(n-2)

有了這個公式，我們轉化成遞迴程式碼就簡單多了。最終的遞迴程式碼是這樣的：

int f(int n) {
  if (n == 1) return 1;
  if (n == 2) return 2;
  return f(n-1) + f(n-2);
}

總結一下，寫遞迴程式碼的關鍵就是找到如何將大問題分解為小問題的規律，並且基於此寫出遞推公式，然後再推敲終止條件，最後將遞推公式和終止條件翻譯成程式碼。

雖然我講了這麼多方法，但是作為初學者的你，現在是不是還是有種想不太清楚的感覺呢？實際上，我剛學遞迴的時候，也有這種感覺，這也是文章開頭我說遞迴程式碼比較難理解的地方。

剛講的電影院的例子，我們的遞迴呼叫只有一個分支，也就是說“一個問題只需要分解為一個子問題”，我們很容易能夠想清楚“遞“和”歸”的每一個步驟，所以寫起來、理解起來都不難。

但是，當我們面對的是一個問題要分解為多個子問題的情況，遞迴程式碼就沒那麼好理解了。

像我剛剛講的第二個例子，人腦幾乎沒辦法把整個“遞”和“歸”的過程一步一步都想清楚。

計算機擅長做重複的事情，所以遞迴正和它的胃口。而我們人腦更喜歡平鋪直敘的思維方式。當我們看到遞迴時，我們總想把遞迴平鋪展開，腦子裡就會迴圈，一層一層往下調，然後再一層一層返回，試圖想搞清楚計算機每一步都是怎麼執行的，這樣就很容易被繞進去。

對於遞迴程式碼，這種試圖想清楚整個遞和歸過程的做法，實際上是進入了一個思維誤區。很多時候，我們理解起來比較吃力，主要原因就是自己給自己製造了這種理解障礙。那正確的思維方式應該是怎樣的呢？

如果一個問題 A 可以分解為若干子問題 B、C、D，你可以假設子問題 B、C、D 已經解決，在此基礎上思考如何解決問題 A。而且，你只需要思考問題 A 與子問題 B、C、D 兩層之間的關係即可，不需要一層一層往下思考子問題與子子問題，子子問題與子子子問題之間的關係。遮蔽掉遞迴細節，這樣子理解起來就簡單多了。

因此，編寫遞迴程式碼的關鍵是，只要遇到遞迴，我們就把它抽象成一個遞推公式，不用想一層層的呼叫關係，不要試圖用人腦去分解遞迴的每個步驟。

遞迴程式碼要警惕堆疊溢位

在實際的軟體開發中，編寫遞迴程式碼時，我們會遇到很多問題，比如堆疊溢位。而堆疊溢位會造成系統性崩潰，後果會非常嚴重。為什麼遞迴程式碼容易造成堆疊溢位呢？我們又該如何預防堆疊溢位呢？

在“棧”那一節講過，函式呼叫會使用棧來儲存臨時變數。每呼叫一個函式，都會將臨時變數封裝為棧幀壓入記憶體棧，等函式執行完成返回時，才出棧。系統棧或者虛擬機器棧空間一般都不大。如果遞迴求解的資料規模很大，呼叫層次很深，一直壓入棧，就會有堆疊溢位的風險。

比如前面的講到的電影院的例子，如果我們將系統棧或者 JVM 堆疊大小設定為 1KB，在求解 f(19999) 時便會出現如下堆疊報錯：

Exception in thread "main" java.lang.StackOverflowError

如何避免出現堆疊溢位呢？

我們可以通過在程式碼中限制遞迴呼叫的最大深度的方式來解決這個問題。遞迴呼叫超過一定深度（比如 1000）之後，我們就不繼續往下再遞迴了，直接返回報錯。還是電影院那個例子，我們可以改造成下面這樣子，就可以避免堆疊溢位了。不過，我寫的程式碼是虛擬碼，為了程式碼簡潔，有些邊界條件沒有考慮，比如 x<=0。

// 全域性變數，表示遞迴的深度。
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，就可以用這種方法，否則這種方法並不是很實用。

遞迴警惕重複計算

除此之外，使用遞迴時還會出現重複計算的問題。剛才我講的第二個遞迴程式碼的例子，如果我們把整個遞迴過程分解一下的話，那就是這樣的：

從圖中，我們可以直觀地看到，想要計算 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 hasSovledList.get(n);
  }
  
  int ret = f(n-1) + f(n-2);
  hasSovledList.put(n, ret);
  return ret;
}

除了堆疊溢位、重複計算這兩個常見的問題。遞迴程式碼還有很多別的問題。

在時間效率上，遞迴程式碼裡多了很多函式呼叫，當這些函式呼叫的數量較大時，就會積聚成一個可觀的時間成本。在空間複雜度上，因為遞迴呼叫一次就會在記憶體棧中儲存一次現場資料，所以在分析遞迴程式碼空間複雜度時，需要額外考慮這部分的開銷，比如我們前面講到的電影院遞迴程式碼，空間複雜度並不是 O(1)，而是 O(n)。

怎麼將遞迴程式碼改為非遞迴

遞迴有利有弊，利是遞迴程式碼的表達力很強，寫起來非常簡潔；而弊就是空間複雜度高、有堆疊溢位的風險、存在重複計算、過多的函式呼叫會耗時較多等問題。所以，在開發過程中，我們要根據實際情況來選擇是否需要用遞迴的方式來實現。

剛才那個電影院的例子，我們拋開場景，只看 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;
}

那是不是所有的遞迴程式碼都可以改為這種迭代迴圈的非遞迴寫法呢？

籠統地講，是的。因為遞迴本身就是藉助棧來實現的，只不過我們使用的棧是系統或者虛擬機器本身提供的，我們沒有感知罷了。如果我們自己在記憶體堆上實現棧，手動模擬入棧、出棧過程，這樣任何遞迴程式碼都可以改寫成看上去不是遞迴程式碼的樣子。

但是這種思路實際上是將遞迴改為了“手動”遞迴，本質並沒有變，而且也並沒有解決前面講到的某些問題，徒增了實現的複雜度。

解答開篇

來看一下開篇的問題：如何找到“最終推薦人”？我的解決方案是這樣的：

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

用三行程式碼就能搞定了，不過在實際專案中，上面的程式碼並不能工作，為什麼呢？這裡面有兩個問題。

第一，如果遞迴很深，可能會有堆疊溢位的問題。

第二，如果資料庫裡存在髒資料，我們還需要處理由此產生的無限遞迴問題。比如 demo 環境下資料庫中，測試工程師為了方便測試，會人為地插入一些資料，就會出現髒資料。如果 A 的推薦人是 B，B 的推薦人是 C，C 的推薦人是 A，這樣就會發生死迴圈。

第一個問題，我前面已經解答過了，可以用限制遞迴深度來解決。第二個問題，也可以用限制遞迴深度來解決。不過，還有一個更高階的處理方法，就是自動檢測 A-B-C-A 這種“環”的存在。如何來檢測環的存在呢？這個我暫時不細說，你可以自己思考下，後面的章節我們還會講。

小結

遞迴是一種非常高效、簡潔的編碼技巧。只要是滿足“三個條件”的問題就可以通過遞迴程式碼來解決。

不過遞迴程式碼也比較難寫、難理解。編寫遞迴程式碼的關鍵就是不要把自己繞進去，正確姿勢是寫出遞推公式，找出終止條件，然後再翻譯成遞迴程式碼。

遞迴程式碼雖然簡潔高效，但是，遞迴程式碼也有很多弊端。比如，堆疊溢位、重複計算、函式呼叫耗時多、空間複雜度高等，所以，在編寫遞迴程式碼的時候，一定要控制好這些副作用。