尾遞歸轉換能加快應用程序的速度，但不是所有的JVM都會做這種轉換，很多算法用尾遞歸方法表示會顯得格外簡明。編譯器會自動把這種方法轉換成循環，以提高程序的性能。但在java語言規范中，并沒有要求一定要作這種轉換，因此，并不是所有的Java虛擬機（JVM）都會做這種轉換。

尾遞歸及其轉換

相當多的程序包含有循環，這些循環運行的時間占了程序總運行時間的很大一部分。這些循環經常要反復更新不止一個變量，而每個變量的更新又經常依靠于其它變量的值。

假如把迭代看成是尾遞歸函數，那么，就可以把這些變量看成是函數的參數。簡單提醒一下：假如一個調用的返回值被作為調用函數的值立即返回，那么，這個遞歸調用就是尾遞歸；尾遞歸不必記住調用時調用函數的上下文。

由于這一特點，在尾遞歸函數和循環之間有一個很好的對應關系：可以簡單地把每個遞歸調用看作是一個循環的多次迭代。但因為所有可變的參數值都一次傳給了遞歸調用，所以比起循環來，在尾遞歸中可以更輕易地得到更新值。而且，難以使用的break語句也經常為函數的簡單返回所替代。

但在Java編程中，用這種方式表示迭代將導致效率低下，因為大量的遞歸調用有導致堆棧溢出的危險。

解決方案比較簡單：因為尾遞歸函數實際上只是編寫循環的一種更簡單的方式，所以就讓編譯器把它們自動轉換成循環形式。這樣您就同時利用了這兩種形式的優點。

但是，盡管大家都熟知如何把一個尾遞歸函數自動轉換成一個簡單循環，Java規范卻不要求做這種轉換。不作這種要求的原因大概是：通常在面向對象的語言中，這種轉換不能靜態地進行。相反地，這種從尾遞歸函數到簡單循環的轉換必須由JIT編譯器動態地進行。

要理解為什么會是這樣，考慮下面一個失敗的嘗試：在Integers集上，把Iterator中的元素相乘。

因為下面的程序中有一個錯誤，所以在運行時會拋出一個異常。但是，就象在本專欄以前的許多文章中已經論證的那樣，一個程序拋出的精確異常（跟很棒的錯誤類型標識符一樣）對于找到錯誤藏在程序的什么地方并沒有什么幫助，我們也不想編譯器以這種方式改變程序，以使編譯的結果代碼拋出一個不同的異常。

清單1：一個把Integer集的Iterator中的元素相乘的失敗嘗試

import java.util.Iterator; 

public class Example { 

public int PRodUCt(Iterator i) { 

return productHelp(i, 0); 

} 
int productHelp(Iterator i, int accumulator) { 

if (i.hasNext()) { 

return productHelp(i, accumulator * ((Integer)i.next()).intValue()); 

} 

else { 

return accumulator; 

} 

} 

} 

注重product方法中的錯誤。product方法通過把accumulator賦值為0調用productHelp。它的值應為1。否則，在類Example的任何實例上調用product都將產生0值，不管Iterator是什么值。

假設這個錯誤終于被改正了，但同時，類Example的一個子類也被創建了，如清單2所示：

清單2：試圖捕捉象清單1這樣的不正確的調用

import java.util.*; 
class Example { 
public int product(Iterator i) { 

return productHelp(i, 1); 

} 
int productHelp(Iterator i, int accumulator) { 

if (i.hasNext()) { 

return productHelp(i, accumulator * ((Integer)i.next()).intValue()); 

} 

else { 

return accumulator; 

} 

} 

} 
// And, in a separate file: