1、程式說明：

事 情是這樣的，使用者的需求是希望將某個路徑作為引數傳遞給工具，然後工具可以遍歷該目錄下的所有子目錄和檔案，將所有資料檔案進行解析轉換。對於這樣一個需 求，最常規的思路是做一個遞迴函式，遇到檔案時處理檔案，遇到目錄時則進行遞迴，這樣很快就可以把某個路徑下的所有子目錄和檔案都遍歷一遍，程式也會顯得 簡潔明瞭。程式碼一般如下：

這樣一段程式在我個人自測階段也沒有發現什麼問題，但是放到雲梯上實際使用的時候問題就來了——棧溢位了。工具丟擲了StackOverflowError異常。

當用戶告知出現這個問題的時候，一剎那間我曾經通讀過的DistCP的原始碼立即在我腦海中閃現了出來，曾經不理解為何要那麼寫的一段程式碼，此時此刻我終於恍然大悟。這個問題的根源在於hdfs檔案系統的目錄層次太深了，因此每一層遞迴累積起來終於將jvm的棧空間撐爆了。自測階段之所以沒有暴露出問題，完全是因為雲梯線上的目錄檔案樹在一個小叢集中很難模擬。

解決這個問題是非常簡單的，只需要將遞迴演算法替換成迭代演算法就可以了。修改後的程式碼如下：

問題雖然解決了，但對jvm堆疊方面技術需要重新審視深究，於是我順便查了些資料學習了一下。眾所周知，堆是有序完全二叉樹，棧是一種先進後出的線性表，棧的特點是速度快，jvm的壓棧和出棧操作都是非常高效的（相對來說，堆的二叉樹遍歷是要比先進後出線性表要慢的）。

“每一個Java應用都唯一對應一個JVM例項，每一個例項唯一對應一個堆。應用程式在執行中所建立的所有類例項或陣列都放在這個堆中,並由應用所有的執行緒共享.跟C/C++不同，Java中分配堆記憶體是自動初始化的。Java中所有物件的儲存空間都是在堆中分配的，但是這個物件的引用卻是在棧中分配,也就是說在建立一個物件時從兩個地方都分配記憶體，在堆中分配的記憶體實際建立這個物件，而在堆疊中分配的記憶體只是一個指向這個堆物件的指標(引用)而已。”

“JVM堆中存的是物件。JVM棧中存的是基本資料型別和JVM堆中物件的引用。一個物件的大小是不可估計的，或者說是可以動態變化的，但是在JVM棧中，一個物件只對應了一個4btye的引用。”

關於這一點，我製作了下面這段程式來進行證實：

這段程式碼執行下來，可以看到預設情況下遞迴深度是10827（java version "1.6.0_65"，系統不同值略有不同）。在stackLevel函式中，增加一個變數（Stringbuf = “”;）之後，再執行一遍，得到的深度為9925。隨意的給字串buf賦值，無論字串長度是多少，9925這個深度都不會發生變化。而如果再增加一個變數申明，則遞迴深度又會再次變小。從而證明了棧只存放指標，而堆負責儲存這件事情。

對於我們一般的本地化應用來說，遍歷目錄這樣的簡單任務，用遞迴還是最高效的，這不僅是因為演算法設計上較為清晰簡單，更因為遞迴利用了棧的高效，程式整體執行速度會比較快。但是對於hdfs這樣的檔案系統來說，目錄的層次深度可能會多達數十甚至數百層，這樣一來，使用遞迴必然會使得函式空間層層堆疊直到導致棧溢位，這也是為什麼DistCP中使用了Stack類來規避遞迴的原因（而我最開始看到這一段的時候只是覺得這樣的演算法費事不討巧，完全沒有理解其深層次的原因）。此外，對於MR程式設計框架來說，計算量的增加或者說計算速度的增加到是可以通過增加slot數來進行彌補的，所以，如果真遇到大量需要遍歷的應用，合理切分到多個slot中去執行才是提高效率的正道。

有趣的是，不同的語言對遞迴深度都有不同的解釋，我嘗試了python和C這兩種語言，python程式碼如下：

得到的結果是1000，且無論在函式stackLevel中增加多少個變數，其遞迴深度都始終是1000。對於python來說遞迴深度是一個可以設定的值，其預設就是1000，可以通過（sys.setrecursionlimit(遞迴深度值)）來進行設定。但是這個設定只不過是起到一個保護的作用，當設定的深度非常大，以至於超過程序記憶體空間時，python依然會報出“Segmentation fault: 11”（11是SIGSEGV訊號，無法捕獲）。

在C裡面，遞迴深度則可以到一個很大的數值，不過最終也會被SIGSEGV訊號中斷。