在Java中談尾遞歸--尾遞歸和垃圾回收的比較

我不是故意在JAVA中談尾遞歸的，由於在JAVA中談尾遞歸真的是要繞好幾個彎，只是我確實只有JAVA學得比較好，雖然確實C是在學校學過還考了90+，真學得沒自學的JAVA好

不過也是由於要繞幾個彎，因此纔會有有意思的東西可寫，另外還有我發現把尾遞歸若是跟JAVA中的GC比對一下，也很有一些妙處（發現尚未人特意比較過）

（不事後來邊寫邊整理思路，寫出來又是另外一個樣子了）

 

轉載請註明：博客園-閣剛廣志，地址： http://www.cnblogs.com/bellkosmos/p/5280619.html 

 

1、首先咱們講講遞歸

1. 遞歸的本質是，某個方法中調用了自身。本質仍是調用一個方法，只是這個方法正好是自身而已
2. 遞歸由於是在自身中調用自身，因此會帶來如下三個顯著特色：
   1. 調用的是同一個方法
   2. 由於1，因此只須要寫一個方法，就可讓你輕鬆調用無數次（不用一個個寫，你定個n就能有n個方法），因此調用的方法數可能很是巨大
   3. 在自身中調用自身，是嵌套調用（棧幀沒法回收，開銷巨大）
3. 由於上面2和3兩個特色，因此遞歸調用最大的詬病就是開銷巨大，棧幀和堆一塊兒爆掉，俗稱內存溢出泄露
   1. 一個誤區，不是由於調用自身而開銷巨大，而是嵌套加上輕易就能無數次調用，使得遞歸能夠很容易開銷巨大

 

既然會致使內存溢出 泄露如此，那確定要想辦法了，方法很簡單，那就是尾遞歸優化

2、尾遞歸優化

1. 尾遞歸優化是利用上面的第一個特色「調用同一個方法」來進行優化的
2. 尾遞歸優化其實包括兩個東西：1）尾遞歸的形式；2）編譯器對尾遞歸的優化
   1. 尾遞歸的形式
      1. 尾遞歸其實只是一種對遞歸的特殊寫法，這種寫法本來並不會帶來跟遞歸不同的影響，它只是寫法不同而已，寫成這樣不會有任何優化效果，該爆的棧和幀都還會爆
      2. 具體不同在哪裏
         1. 前面說了，遞歸的本質是某個方法調用了自身，尾遞歸這種形式就要求：某個方法調用自身這件事，必定是該方法作的最後一件事（因此當有須要返回值的時候會是return f(n)，沒有返回的話就直接是f(n)了）
      3. 要求很簡單，就一條，可是有一些常見的誤區
         1. 這個f(n)外不能加其餘東西，由於這就不是最後一件事了，值返回來後還要再幹點其餘的活，變量空間還須要保留
            1. 好比若是有返回值的，你不能：乘個常數 return 3f(n)；乘個n return n*f(n)；甚至是 f(n)+f(n-1)
      4. 另外，使用return的尾遞歸還跟函數式編程有一點關係
   2. 編譯器對尾遞歸的優化
      1. 上面說了，你光手動寫成尾遞歸的形式，並無什麼卵用，要實現優化，還須要編譯器中加入了對尾遞歸優化的機制
      2. 有了這個機制，編譯的時候，就會自動利用上面的特色一來進行優化
      3. 具體是怎麼優化的：
         1. 簡單說就是重複利用同一個棧幀，不只不用釋放上一個，連下一個新的都不用開，效率很是高（有人作實驗，這個比遞推比迭代都要效率高）
3. 爲何寫成尾遞歸的形式，編譯器就能優化了？或者說【編譯器對尾遞歸的優化】的一些深層思想
   1. 說是深層思想，其實也是由於正好編譯器其實在這裏沒作什麼複雜的事，因此很簡單
   2. 因爲這兩方面的緣由，尾遞歸優化得以實現，並且效果很好
      1. 由於在遞歸調用自身的時候，這一層函數已經沒有要作的事情了，雖然被遞歸調用的函數是在當前的函數裏，可是他們之間的關係已經在傳參的時候了斷了，也就是這一層函數的全部變量什麼的都不會再被用到了，因此當前函數雖然沒有執行完，不能彈出棧，但它確實已經能夠出棧了，這是一方面
      2. 另外一方面，正由於調用的是自身，因此須要的存儲空間是一毛同樣的，那乾脆從新刷新這些空間給下一層利用就行了，不用銷燬再另開空間
   3. 有人對寫成尾遞歸形式的說法是【爲了告訴編譯器這塊要尾遞歸】，這種說法可能會致使誤解，由於不是隻告訴編譯器就行，而是你須要作優化的前半部分，以後編譯器作後半部分
4. 因此總結：爲了解決遞歸的開銷大問題，使用尾遞歸優化，具體分兩步：1）你把遞歸調用的形式寫成尾遞歸的形式；2）編譯器碰到尾遞歸，自動按照某種特定的方式進行優化編譯

舉例：

（沒有使用尾遞歸的形式）

def recsum(x):
  if x == 1:
    return x
  else:
    return x + recsum(x - 1)

（使用尾遞歸的形式）

def tailrecsum(x, running_total=0):
  if x == 0:
    return running_total
  else:
    return tailrecsum(x - 1, running_total + x)

 

但不是全部語言的編譯器都作了尾遞歸優化。好比C實現了，JAVA沒有去實現

說到這裏你很容易聯想到JAVA中的自動垃圾回收機制，同是處理內存問題的機制，尾遞歸優化跟垃圾回收是否是有什麼關係，這是否是就是JAVA不實現尾遞歸優化的緣由？

 

3、因此下面要講一下垃圾回收（GC）

1. 首先咱們須要談一下內存機制，這裏咱們須要瞭解內存機制的兩個部分：棧和堆。下面雖然是在說JAVA，可是C也是差很少的
   1. 在Java中， JVM中的棧記錄了線程的方法調用。每一個線程擁有一個棧。在某個線程的運行過程當中， 若是有新的方法調用，那麼該線程對應的棧就會增長一個存儲單元，即棧幀 (frame)。在frame 中，保存有該方法調用的參數、局部變量和返回地址
   2. Java的參數和局部變量只能是 基本類型 的變量(好比 int)，或者對象的引用(reference) 。所以，在棧中，只保存有基本類型的變量和對象引用。而引用所指向的對象保存在堆中。
2. 而後由棧和堆的空間管理方式的不一樣，引出垃圾回收的概念
   1. 當被調用方法運行結束時，該方法對應的幀將被刪除，參數和局部變量所佔據的空間也隨之釋放。線程回到原方法，繼續執行。當全部的棧都清空時，程序也隨之運行結束。
   2. 如上所述，棧 (stack)能夠本身照顧本身。但堆必需要當心對待。堆是 JVM中一塊可自由分配給對象的區域。當咱們談論垃圾回收 (garbage collection) 時，咱們主要回收堆(heap)的空間。
   3. Java的普通對象存活在堆中。與棧不一樣，堆的空間不會隨着方法調用結束而清空（即便它在棧上的引用已經被清空了）（也不知道爲何不直接同步清空）。所以，在某個方法中建立的對象，能夠在方法調用結束以後，繼續存在於堆中。這帶來的一個問題是，若是咱們不斷的建立新的對象，內存空間將最終消耗殆盡。
   4. 若是沒有垃圾回收機制的話，你就須要手動地顯式分配及釋放內存，若是你忘了去釋放內存，那麼這塊內存就沒法重用了（不論是什麼局部變量仍是其餘的什麼）。這塊內存被佔有了卻沒被使用，這種場景被稱之爲內存泄露
3. 因此不論是C仍是JAVA，最原始的狀況，都是須要手動釋放堆中的對象，C到如今也是這樣，因此你常常須要考慮對象的生存週期，可是JAVA則引入了一個自動垃圾回收的機制，它能智能地釋放那些被斷定已經沒有用的對象

 

4、如今咱們就能夠比較一下尾遞歸優化和垃圾回收了

1. 他們最本質的區別是，尾遞歸優化解決的是內存溢出的問題，而垃圾回收解決的是內存泄露的問題
   1. 內存泄露：指程序中動態分配內存給一些臨時對象，可是對象不會被GC所回收，它始終佔用內存。即被分配的對象可達但已無用。
   2. 內存溢出：指程序運行過程當中沒法申請到足夠的內存而致使的一種錯誤。內存溢出一般發生於OLD段或Perm段垃圾回收後，仍然無內存空間容納新的Java對象的狀況。
   3. 從定義上能夠看出內存泄露是內存溢出的一種誘因，不是惟一因素。
2. 自動垃圾回收機制的特色是：
   1. 解決了全部狀況下的內存泄露的問題，但還能夠因爲其餘緣由內存溢出
   2. 針對內存中的堆空間
   3. 正在運行的方法中的堆中的對象是不會被管理的，由於還有引用（棧幀沒有被清空）
      1. 通常簡單的自動垃圾回收機制是採用 引用計數 (reference counting)的機制。每一個對象包含一個計數器。當有新的指向該對象的引用時，計數器加 1。當引用移除時，計數器減 1，當計數器爲0時，認爲該對象能夠進行垃圾回收
3. 與之相對，尾遞歸優化的特色是：
   1. 優化了遞歸調用時的內存溢出問題
   2. 針對內存中的堆空間和棧空間
   3. 只在遞歸調用的時候使用，並且只能對於寫成尾遞歸形式的遞歸進行優化
   4. 正在運行的方法的堆和棧空間正是優化的目標

 

最後能夠解答一下前頭提出的問題

1. 經過比較能夠發現尾遞歸和GC是徹底不同的，JAVA不會是由於有GC因此不須要尾遞歸優化。那爲何呢，我看到有的說法是：JAVA編寫組不實現尾遞歸優化是以爲麻煩又沒有太大的必要，就懶得實現了（原話是：在日程表上，可是很是靠後），官方的建議是不使用遞歸，而是使用while循環，迭代，遞推

 

參考資料：

http://it.deepinmind.com/jvm/2014/04/16/tail-call-optimization-and-java.html

http://book.51cto.com/art/201212/370096.htm