翻譯連載 | 第 9 章：遞歸（下）－《JavaScript輕量級函數式編程》 |《你不知道的JS》姊妹篇

• 原文地址：Functional-Light-JS
• 原文做者：Kyle Simpson－《You-Dont-Know-JS》做者

關於譯者：這是一個流淌着滬江血液的純粹工程：認真，是 HTML 最堅實的樑柱；分享，是 CSS 裏最閃耀的一瞥；總結，是 JavaScript 中最嚴謹的邏輯。通過捶打磨練，成就了本書的中文版。本書包含了函數式編程之精髓，但願能夠幫助你們在學習函數式編程的道路上走的更順暢。比心。

譯者團隊（排名不分前後）：阿希、blueken、brucecham、cfanlife、dail、kyoko-df、l3ve、lilins、LittlePineapple、MatildaJin、冬青、pobusama、Cherry、蘿蔔、vavd317、vivaxy、萌萌、zhouyao

第 9 章：遞歸（下）

棧、堆

一塊兒看下以前的兩個遞歸函數 isOdd(..) 和 isEven(..)：

function isOdd(v) {
	if (v === 0) return false;
	return isEven( Math.abs( v ) - 1 );
}

function isEven(v) {
	if (v === 0) return true;
	return isOdd( Math.abs( v ) - 1 );
}
複製代碼

若是你執行下面這行代碼，在大多數瀏覽器裏面都會報錯：

isOdd( 33333 );			// RangeError: Maximum call stack size exceeded
複製代碼

這個錯誤是什麼狀況？引擎拋出這個錯誤，是由於它試圖保護系統內存不會被你的程序耗盡。爲了解釋這個問題，咱們須要先看看當函數調用時JS引擎中發生了什麼。

每一個函數調用都將開闢出一小塊稱爲堆棧幀的內存。堆棧幀中包含了函數語句當前狀態的某些重要信息，包括任意變量的值。之因此這樣，是由於一個函數暫停去執行另一個函數，而另一個函數運行結束後，引擎須要返回到以前暫停時候的狀態繼續執行。

當第二個函數開始執行，堆棧幀增長到 2 個。若是第二個函數又調用了另一個函數，堆棧幀將增長到 3 個，以此類推。「棧」的意思是，函數被它前一個函數調用時，這個函數幀會被「推」到最頂部。當這個函數調用結束後，它的幀會從堆棧中退出。

看下這段程序：

function foo() {
	var z = "foo!";
}

function bar() {
	var y = "bar!";
	foo();
}

function baz() {
	var x = "baz!";
	bar();
}

baz();
複製代碼

來一步步想象下這個程序的堆棧幀：

注意： 若是這些函數間沒有相互調用，而只是依次執行 -- 好比前一個函數運行結束後纔開始調用下一個函數 baz(); bar(); foo(); -- 則堆棧幀並無產生；由於在下一個函數開始以前，上一個函數運行結束並把它的幀從堆棧裏面移除了。

因此，每個函數運行時候，都會佔用一些內存。對多數程序來講，這沒什麼大不了的，不是嗎？可是，一旦你引用了遞歸，問題就不同了。 雖然你幾乎確定不會在一個調用棧中手動調用成千（或數百）次不一樣的函數，但你很容易看到產生數萬個或更多遞歸調用的堆棧。

當引擎認爲調用棧增長的太多而且應該中止增長時候，它會以主觀的限制來阻止當前步驟，因此 isOdd(..) 或 isEven(..) 函數拋出了 RangeError 未知錯誤。這不太多是內存接近零時候產生的限制，而是引擎的預測，由於若是這種程序持續運行下去，內存會爆掉的。因爲引擎沒法判斷一個程序最終是否會中止，因此它必須作出肯定的猜想。

引擎的限制因狀況而定。規範裏面並無任何說明，所以，它也不是 必需的。但若是沒有限制的話，設備很容易遭到破壞或惡意代碼攻擊，故而幾乎全部的JS引擎都有一個限制。不一樣的設備環境、不一樣的引擎，會有不一樣的限制，也就沒法預測或保證函數調用棧能調用多少次。

在處理大數據量時候，這個限制對於開發人員來講，會對遞歸的性能有必定的要求。我認爲，這種限制也多是形成開發人員不喜歡使用遞歸編程的最大緣由。 遺憾的是，遞歸編程是一種編程思想而不是主流的編程技術。

尾調用

遞歸編程和內存限制都要比 JS 技術出現的早。追溯到上世紀 60 年代，當時開發人員想使用遞歸編程並但願運行在他們強大的計算機的設備，而所謂強大計算機的內存，尚遠不如咱們今天在手錶上的內存。

幸運的是，在那個但願的原野上，進行了一個有力的觀測。該技術稱爲 尾調用。

它的思路是若是一個回調從函數 baz() 轉到函數 bar() 時候，而回調是在函數 baz() 的最底部執行 -- 也就是尾調用 -- 那麼 baz() 的堆棧幀就再也不須要了。也就意謂着，內存能夠被回收，或只需簡單的執行 bar() 函數。 如圖所示：

尾調用並非遞歸特有的；它適用於任何函數調用。可是，在大多數狀況下，你的手動非遞歸調用棧不太可能超過 10 級，所以尾調用對你程序內存的影響可能至關低。

在遞歸的狀況下，尾調用做用很明顯，由於這意味着遞歸堆棧能夠「永遠」運行下去，惟一的性能問題就是計算，而再也不是固定的內存限制。在固定的內存中尾遞歸能夠運行 O(1) （常數階時間複雜度計算）。

這些技術一般被稱爲尾調用優化（TCO），但重點在於從優化技術中，區分出在固定內存空間中檢測尾調用運行的能力。從技術上講，尾調用並不像大多數人所想的那樣，它們的運行速度可能比普通回調還慢。TCO 是關於把尾調用更加高效運行的一些優化技術。

正確的尾調用 (PTC)

在 ES6 出來以前，JavaScript 對尾調用一直沒明確規定（也沒有禁用）。ES6 明確規定了 PTC 的特定形式，在 ES6 中，只要使用尾調用，就不會發生棧溢出。實際上這也就意味着，只要正確的使用 PTC，就不會拋出 RangeError 這樣的異常錯誤。

首先，在 JavaScript 中應用 PTC，必須以嚴格模式書寫代碼。若是你之前沒有用過嚴格模式，你得試着用用了。那麼，您，應該已經在使用嚴格模式了吧！？

其次，正確 的尾調用就像這個樣子：

return foo( .. );
複製代碼

換句話說，函數調用應該放在最後一步去執行，而且無論返回什麼東東，都得有返回（ return ）。這樣的話，JS 就再也不須要當前的堆棧幀了。

下面這些 不能 稱之爲 PTC：

foo();
return;

// 或

var x = foo( .. );
return x;

// 或

return 1 + foo( .. );
複製代碼

注意： 一些 JS 引擎 可以 把 var x = foo(); return x; 自動識別爲 return foo();，這樣也能夠達到 PTC 的效果。但這畢竟不符合規範。

foo(..) 運行結束以後 1+ 這部分纔開始執行，因此此時的堆棧幀依然存在。

不過，下面這個 是 PTC：

return x ? foo( .. ) : bar( .. );
複製代碼

x 進行條件判斷以後，或執行 foo(..)，或執行 bar(..)，不論執行哪一個，返回結果都會被 return 返回掉。這個例子符合 PTC 規範。

爲了不堆棧增長，PTC 要求全部的遞歸必須是在尾部調用，所以，二分法遞歸 —— 兩次（或以上）遞歸調用 —— 是不能實現 PTC 的。咱們曾在文章的前面部分展現過把二分法遞歸轉變爲相互遞歸的例子。也許咱們能夠試着化整爲零，把多重遞歸拆分紅符合 PTC 規範的單個函數回調。

重構遞歸

若是你想用遞歸來處理問題，卻又超出了 JS 引擎的內存堆棧，這時候就須要重構下你的遞歸調用，使它可以符合 PTC 規範（或着避免嵌套調用）。這裏有一些重構方法也許能夠用到，但須要根據實際狀況權衡。

可讀性強的代碼，是咱們的終級目標 —— 謹記，謹記。若是使用遞歸後會形成代碼難以閱讀/理解，那就 不要使用遞歸；換個容易理解的方法吧。

更換堆棧

對遞歸來講，最主要的問題是它的內存使用狀況。保持堆棧幀跟蹤函數調用的狀態，並將其分派給下一個遞歸調用迭。若是咱們弄清楚瞭如何從新排列咱們的遞歸，就能夠用 PTC 實現遞歸，並利用 JS 引擎對尾調用的優化處理，那麼咱們就不用在內存中保留當前的堆棧幀了。

來回顧下以前用到的一個求和的例子：

function sum(num1,...nums) {
	if (nums.length == 0) return num1;
	return num1 + sum( ...nums );
}
複製代碼

這個例子並不符合 PTC 規範。sum(...nums) 運行結束以後，num1 與 sum(...nums) 的運行結果進行了累加。這樣的話，當其他參數 ...nums 再次進行遞歸調用時候，爲了獲得其與 num1 累加的結果，必需要保留上一次遞歸調用的堆棧幀。

重構策略的關鍵點在於，咱們能夠經過把 置後 處理累加改成 提早 處理，來消除對堆棧的依賴，而後將該部分結果做爲參數傳遞到遞歸調用。換句話說，咱們不用在當前運用函數的堆棧幀中保留 num1 + sum(...num1) 的總和，而是把它傳遞到下一個遞歸的堆棧幀中，這樣就能釋放當前遞歸的堆棧幀。

開始以前，咱們作些改動：把部分結果做爲一個新的第一個參數傳入到函數 sum(..)：

function sum(result,num1,...nums) {
	// ..
}
複製代碼

此次咱們先把 result 和 num1 提早計算，而後把 result 做爲參數一塊兒傳入：

"use strict";

function sum(result,num1,...nums) {
	result = result + num1;
	if (nums.length == 0) return result;
	return sum( result, ...nums );
}
複製代碼

如今 sum(..) 已經符合 PTC 優化規範了！耶！

可是還有一個缺點，咱們修改了函數的參數傳遞形式後，用法就跟之前不同了。調用者不得不在須要求和的那些參數的前面，再傳遞一個 0 做爲第一個參數。

sum( /*initialResult=*/0, 3, 1, 17, 94, 8 );		// 123
複製代碼

這就尷尬了。

一般，你們的處理方式是，把這個尷尬的遞歸函數從新命名，而後定義一個接口函數把問題隱藏起來：

"use strict";

function sumRec(result,num1,...nums) {
	result = result + num1;
	if (nums.length == 0) return result;
	return sumRec( result, ...nums );
}

function sum(...nums) {
	return sumRec( /*initialResult=*/0, ...nums );
}

sum( 3, 1, 17, 94, 8 );								// 123
複製代碼

狀況好了些。但依然有問題：以前只須要一個函數就能解決的事，如今咱們用了兩個。有時候你會發現，在處理這類問題上，有些開發者用內部函數把遞歸 「藏了起來」：

"use strict";

function sum(...nums) {
	return sumRec( /*initialResult=*/0, ...nums );

	function sumRec(result,num1,...nums) {
		result = result + num1;
		if (nums.length == 0) return result;
		return sumRec( result, ...nums );
	}
}

sum( 3, 1, 17, 94, 8 );								// 123
複製代碼

這個方法的缺點是，每次調用外部函數 sum(..)，咱們都得從新建立內部函數 sumRec(..)。咱們能夠把他們平級放置在當即執行的函數中，只暴露出咱們想要的那個的函數：

"use strict";

var sum = (function IIFE(){

	return function sum(...nums) {
		return sumRec( /*initialResult=*/0, ...nums );
	}

	function sumRec(result,num1,...nums) {
		result = result + num1;
		if (nums.length == 0) return result;
		return sumRec( result, ...nums );
	}

})();

sum( 3, 1, 17, 94, 8 );								// 123
複製代碼

好啦，如今即符合了 PTC 規範，又保證了 sum(..) 參數的整潔性，調用者不須要了解函數的內部實現細節。完美！

但是...天吶，原本是簡單的遞歸函數，如今卻出現了不少噪點。可讀性已經明顯下降。至少說，這是不成功的。有些時候，這只是咱們能作的最好的。

幸運的事，在一些其它的例子中，好比上一個例子，有一個比較好的方式。一塊兒從新看下：

"use strict";

function sum(result,num1,...nums) {
	result = result + num1;
	if (nums.length == 0) return result;
	return sum( result, ...nums );
}

sum( /*initialResult=*/0, 3, 1, 17, 94, 8 );		// 123
複製代碼

也許你會注意到，result 就像 num1 同樣，也就是說，咱們能夠把列表中的第一個數字做爲咱們的運行總和；這甚至包括了第一次調用的狀況。咱們須要的是從新命名這些參數，使函數清晰可讀：

"use strict";

function sum(num1,num2,...nums) {
	num1 = num1 + num2;
	if (nums.length == 0) return num1;
	return sum( num1, ...nums );
}

sum( 3, 1, 17, 94, 8 );								// 123
複製代碼

帥呆了。比以前好了不少，嗯？！我認爲這種模式在聲明/合理和執行之間達到了很好的平衡。

讓咱們試着重構下前面的 maxEven(..)（目前還不符合 PTC 規範）。就像以前咱們把參數的和做爲第一個參數同樣，咱們能夠依次減小列表中的數字，同時一直把遇到的最大偶數做爲第一個參數。

爲了清楚起見，咱們可能使用算法策略（相似於咱們以前討論過的）：

1. 首先對前兩個參數 num1 和 num2 進行對比。
2. 若是 num1 是偶數，而且 num1 大於 num2，num1 保持不變。
3. 若是 num2 是偶數，把 num2 賦值給 num1。
4. 不然的話，num1 等於 undefined。
5. 若是除了這兩個參數以外，還存在其它參數 nums，把它們與 num1 進行遞歸對比。
6. 最後，無論是什麼值，只需返回 num1。

依照上面的步驟，代碼以下：

"use strict";

function maxEven(num1,num2,...nums) {
	num1 =
		(num1 % 2 == 0 && !(maxEven( num2 ) > num1)) ?
			num1 :
			(num2 % 2 == 0 ? num2 : undefined);

	return nums.length == 0 ?
		num1 :
		maxEven( num1, ...nums )
}
複製代碼

注意： 函數第一次調用 maxEven(..) 並非爲了 PTC 優化，當它只傳遞 num2 時，只遞歸一級就返回了；它只是一個避免重複 ％ 邏輯的技巧。所以，只要該調用是徹底不一樣的函數，就不會增長遞歸堆棧。第二次調用 maxEven(..) 是基於 PTC 優化角度的真正遞歸調用，所以不會隨着遞歸的進行而形成堆棧的增長。

重申下，此示例僅用於說明將遞歸轉化爲符合 PTC 規範以優化堆棧（內存）使用的方法。求最大偶數值的更直接方法多是，先對參數列表中的 nums 過濾，而後冒泡或排序處理。

基於 PTC 重構遞歸，當然對簡單的聲明形式有一些影響，但依然有理由去作這樣的事。不幸的是，存在一些遞歸，即便咱們使用了接口函數來擴展，也不會很好，所以，咱們須要有不一樣的思路。

後繼傳遞格式 （CPS）

在 JavaScript 中， continuation 一詞一般用於表示在某個函數完成後指定須要執行的下一個步驟的回調函數。組織代碼，使得每一個函數在其結束時接收另外一個執行函數，被稱爲後繼傳遞格式（CPS）。

有些形式的遞歸，其實是沒法按照純粹的 PTC 規範重構的，特別是相互遞歸。咱們以前提到過的 fib(..) 函數，以及咱們派生出來的相互遞歸形式。這兩個狀況，皆是存在多個遞歸調用，這些遞歸調用阻礙了 PTC 內存優化。

可是，你能夠執行第一個遞歸調用，並將後續遞歸調用包含在後續函數中並傳遞到第一個調用。儘管這意味着最終須要在堆棧中執行更多的函數，但因爲後繼函數所包含的都是 PTC 形式的，因此堆棧內存的使用狀況不會無限增加。

把 fib(..) 作以下修改：

"use strict";

function fib(n,cont = identity) {
	if (n <= 1) return cont( n );
	return fib(
		n - 2,
		n2 => fib(
			n - 1,
			n1 => cont( n2 + n1 )
		)
	);
}
複製代碼

仔細看下都作了哪些事情。首先，咱們默認用了第三章中的 cont(..) 後繼函數表示 identity(..)；記住，它只簡單的返回傳遞給它的任何東西。

更重要的是，這裏面增長了不只僅是一個而是兩個後續函數。第一個後續函數接收 fib(n-2) 的運行結果做爲參數 n2。第二個內部後續函數接收 fib(n-1)的運行結果做爲參數 n1。當獲得 n1 和 n2 的值後，二者再相加 （n2 + n1），相加的運行結果會傳入到下一個後續函數 cont(..)。

也許這將有助於咱們梳理下流程：就像咱們以前討論的，在遞歸堆棧以後，當咱們傳遞部分結果而不是返回它們時，每一步都被包含在一個後續函數中，這拖慢了計算速度。這個技巧容許咱們執行多個符合 PTC 規範的步驟。

在靜態語言中，CPS一般爲尾調用提供了編譯器能夠自動識別並從新排列遞歸代碼以利用的機會。很惋惜，不能用在原生 JS 上。

在 JavaScript 中，你得本身書寫出符合 CPS 格式的代碼。這並非明智的作法；以命令符號聲明的形式確定會讓內容有些不清楚。 但總的來講，這種形式仍然要比 for 循環更具備聲明性。

警告： 咱們須要注意的一個比較重要的事項是，在 CPS 中，建立額外的內部後續函數仍然消耗內存，但有些不一樣。並非以前的堆棧幀累積，閉包只是消耗多餘的內存空間（通常狀況下，是堆棧裏面的多餘內存空間）。在這些狀況下，引擎彷佛沒有啓動 RangeError 限制，但這並不意味着你的內存使用量是按比例固定好的。

彈簧牀

除了 CPS 後續傳遞格式以外，另一種內存優化的技術稱爲彈簧牀。在彈簧牀格式的代碼中，一樣的建立了相似 CPS 的後續函數，不一樣的是，它們沒有被傳遞，而是被簡單的返回了。

再也不是函數調用另外的函數，堆棧的深度也不會大於一層，由於每一個函數只會返回下一個將調用的函數。循環只是繼續運行每一個返回的函數，直到再也沒有函數可運行。

彈簧牀的優勢之一是在非 PTC 環境下你同樣能夠應用此技術。另外一個優勢是每一個函數都是正常調用，而不是 PTC 優化，因此它能夠運行得更快。

一塊兒來試下 trampoline(..)：

function trampoline(fn) {
	return function trampolined(...args) {
		var result = fn( ...args );

		while (typeof result == "function") {
			result = result();
		}

		return result;
	};
}
複製代碼

當返回一個函數時，循環繼續，執行該函數並返回其運行結果，而後檢查返回結果的類型。一旦返回的結果類型不是函數，彈簧牀就認爲函數調用完成了並返回結果值。

因此咱們可能須要使用前面講到的，將部分結果做爲參數傳遞的技巧。如下是咱們在以前的數組求和中使用此技巧的示例：

var sum = trampoline(
	function sum(num1,num2,...nums) {
		num1 = num1 + num2;
		if (nums.length == 0) return num1;
		return () => sum( num1, ...nums );
	}
);

var xs = [];
for (let i=0; i<20000; i++) {
	xs.push( i );
}

sum( ...xs );					// 199990000
複製代碼

缺點是你須要將遞歸函數包裹在執行彈簧牀功能的函數中; 此外，就像 CPS 同樣，須要爲每一個後續函數建立閉包。然而，與 CPS 不同的地方是，每一個返回的後續數數，運行並當即完成，因此，當調用堆棧的深度用盡時，引擎中不會累積愈來愈多的閉包。

除了執行和記憶性能以外，彈簧牀技術優於CPS的優勢是它們在聲明遞歸形式上的侵入性更小，因爲你沒必要爲了接收後續函數的參數而更改函數參數，因此除了執行和內存性能以外，彈簧牀技術優於 CPS 的地方還有，它們在聲明遞歸形式上侵入性更小。雖然彈簧牀技術並非理想的，但它們能夠有效地在命令循環代碼和聲明性遞歸之間達到平衡。

總結

遞歸，是指函數遞歸調用自身。呃，這就是遞歸的定義。明白了吧！？

直遞歸是指對自身至少調用一次，直到知足基本條件才能中止調用。多重遞歸（像二分遞歸）是指對自身進行屢次調用。相互遞歸是當兩個或以上函數循環遞歸 相互 調用。而遞歸的優勢是它更具聲明性，所以一般更易於閱讀。

遞歸的優勢是它更具聲明性，所以一般更易於閱讀。缺點一般是性能方面，可是相比執行速度，更多的限制在於內存方面。

尾調用是經過減小或釋放堆棧幀來節約內存空間。要在 JavaScript 中實現尾調用 「優化」，須要基於嚴格模式和適當的尾調用（ PTC ）。咱們也能夠混合幾種技術來將非 PTC 遞歸函數重構爲 PTC 格式，或者至少能經過平鋪堆棧來節約內存空間。

謹記：遞歸應該使代碼更容易讀懂。若是你誤用或濫用遞歸，代碼的可讀性將會比命令形式更糟。千萬不要這樣作。

** 【上一章】翻譯連載 | 第 9 章：遞歸（上）－《JavaScript輕量級函數式編程》 |《你不知道的JS》姊妹篇 **

iKcamp原創新書《移動Web前端高效開發實戰》已在亞馬遜、京東、噹噹開售。

滬江Web前端上海團隊招聘【Web前端架構師】，有意者簡歷至：zhouyao@hujiang.com

iKcamp官網：www.ikcamp.com

---

2019年，iKcamp原創新書《Koa與Node.js開發實戰》已在京東、天貓、亞馬遜、噹噹開售啦！