尾遞歸轉(zhuǎn)換能加快應用程序的速度,但不是所有的JVM都會做這種轉(zhuǎn)換,很多算法用尾遞歸方法表示會顯得格外簡明。編譯器會自動把這種方法轉(zhuǎn)換成循環(huán),以提高程序的性能。但在java語言規(guī)范中,并沒有要求一定要作這種轉(zhuǎn)換,因此,并不是所有的Java虛擬機(JVM)都會做這種轉(zhuǎn)換。
尾遞歸及其轉(zhuǎn)換
相當多的程序包含有循環(huán),這些循環(huán)運行的時間占了程序總運行時間的很大一部分。這些循環(huán)經(jīng)常要反復更新不止一個變量,而每個變量的更新又經(jīng)常依靠于其它變量的值。
假如把迭代看成是尾遞歸函數(shù),那么,就可以把這些變量看成是函數(shù)的參數(shù)。簡單提醒一下:假如一個調(diào)用的返回值被作為調(diào)用函數(shù)的值立即返回,那么,這個遞歸調(diào)用就是尾遞歸;尾遞歸不必記住調(diào)用時調(diào)用函數(shù)的上下文。
由于這一特點,在尾遞歸函數(shù)和循環(huán)之間有一個很好的對應關系:可以簡單地把每個遞歸調(diào)用看作是一個循環(huán)的多次迭代。但因為所有可變的參數(shù)值都一次傳給了遞歸調(diào)用,所以比起循環(huán)來,在尾遞歸中可以更輕易地得到更新值。而且,難以使用的break語句也經(jīng)常為函數(shù)的簡單返回所替代。
但在Java編程中,用這種方式表示迭代將導致效率低下,因為大量的遞歸調(diào)用有導致堆棧溢出的危險。
解決方案比較簡單:因為尾遞歸函數(shù)實際上只是編寫循環(huán)的一種更簡單的方式,所以就讓編譯器把它們自動轉(zhuǎn)換成循環(huán)形式。這樣您就同時利用了這兩種形式的優(yōu)點。
但是,盡管大家都熟知如何把一個尾遞歸函數(shù)自動轉(zhuǎn)換成一個簡單循環(huán),Java規(guī)范卻不要求做這種轉(zhuǎn)換。不作這種要求的原因大概是:通常在面向?qū)ο蟮恼Z言中,這種轉(zhuǎn)換不能靜態(tài)地進行。相反地,這種從尾遞歸函數(shù)到簡單循環(huán)的轉(zhuǎn)換必須由JIT編譯器動態(tài)地進行。
要理解為什么會是這樣,考慮下面一個失敗的嘗試:在Integers集上,把Iterator中的元素相乘。
因為下面的程序中有一個錯誤,所以在運行時會拋出一個異常。但是,就象在本專欄以前的許多文章中已經(jīng)論證的那樣,一個程序拋出的精確異常(跟很棒的錯誤類型標識符一樣)對于找到錯誤藏在程序的什么地方并沒有什么幫助,我們也不想編譯器以這種方式改變程序,以使編譯的結(jié)果代碼拋出一個不同的異常。
清單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調(diào)用productHelp。它的值應為1。否則,在類Example的任何實例上調(diào)用product都將產(chǎn)生0值,不管Iterator是什么值。
假設這個錯誤終于被改正了,但同時,類Example的一個子類也被創(chuàng)建了,如清單2所示:
清單2:試圖捕捉象清單1這樣的不正確的調(diào)用
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:
新聞熱點
疑難解答