上一個文章 已經介紹了基本類型和引用類型的性能差異（主要是由于記憶體配置設定方式不同導緻）。為了給列位看官加深印象，今天拿一個具體的例子來實地操作一把，看看優化的效果如何。<!-- program-think-->
★關于需求
首先描述一下需求，具體如下：給定一個String對象，過濾掉除數字 （字元'0'-'9'）以外的其它字元。要求時間開銷盡可能小。過濾函數的原型如下：String filter(String str);
針對上述需求，我寫了5個不同的過濾函數。為了叙述友善，分别稱為filter1到filter5。其中filter1性能最差、filter5性能最 好。在你接着看後續的内容之前，你先暗自思考一下，如果由你來實作該函數，大概會寫成什麼樣？最好把你想好的函數寫下來，便于後面的對比。
★代碼實作
◇測試代碼
為了友善測試性能，先準備好一個測試代碼，具體如下：
class Test
{
public static void main(String[] args)
{
if(args.length != 1)
{
return;
}
String str = "";
long nBegin = System.currentTimeMillis();
for(int i=0; i<1024*1024; i++)
{
str = filterN(args[0]); //此處調用某個具體的過濾函數
}
long nEnd = System.currentTimeMillis();
System.out.println(nEnd-nBegin);
System.out.println(str);
}
};
在沒有想好你的實作方式之前，先别偷看後續内容哦！另外，先注明一下，我使用的Java環境是JDK 1.5.0-09，使用的測試字元串為“D186783E36B721651E8AF96AB1C4000B”。由于JDK版本和機器性能不盡相同，你在 自己機器上測試的結果可能和我下面給出的數值不太一樣。
◇版本1
先來揭曉性能最差的filter1，代碼如下：
private static String filter1(String strOld)
{
String strNew = new String();
for(int i=0; i<strOld.length(); i++)
{
if('0'<=strOld.charAt(i) && strOld.charAt(i)<='9')
{
strNew += strOld.charAt(i);
}
}
return strNew;
}
如果你的代碼不幸和filter1雷同，那你的Java功底可就是相當糟糕了，連字元串拼接需要用StringBuffer來優化都沒搞明白。
為了和後續對比，先記下filter1的處理時間，大約在8.81-8.90秒之間。
◇版本2
再來看看filter2，代碼如下：
private static String filter2(String strOld)
{
StringBuffer strNew = new StringBuffer();
for(int i=0; i<strOld.length(); i++)
{
if('0'<=strOld.charAt(i) && strOld.charAt(i)<='9')
{
strNew.append(strOld.charAt(i));
}
}
return strNew.toString();
}
其實剛才在評價filter1的時候，已經洩露了filter2的天機。filter2通過使用StringBuffer來優化連接配接字元串的性能。為什 麼StringBuffer連接配接字元串的性能比String好，這個已經是老生常談，我就不細說了。尚不清楚的同學自己上Google一查便知。我估計應 該有挺多同學會寫出類似filter2的代碼。
另外，JDK 1.5新增加了StringBuilder，性能會比StringBuffer更好，不過考慮到有可能要拿到其它版本的JDK上作對比測試，而且 StringBuilder和StringBuffer之間的差異不是本文讨論的重點，是以後面的例子都使用StringBuffer來實作。
filter2的處理時間大約為2.14-2.18秒，提升了大約4倍。
◇版本3
接着看看filter3，代碼如下：
private static String filter3(String strOld)
{
StringBuffer strNew = new StringBuffer();
int nLen = strOld.length();
for(int i=0; i<nLen; i++)
{
char ch = strOld.charAt(i);
if('0'<=ch && ch<='9')
{
strNew.append(ch);
}
}
return strNew.toString();
}
乍一看filter3和filter2的代碼差不多嘛！你再仔細瞧一瞧，原來先把strOld.charAt(i)指派給char變量，節省了重複調用 charAt()方法的開銷；另外把strOld.length()先儲存為nLen，也節省了重複調用length()的開銷。能想到這一步的同學，估 計是比較細心的。
經過此一優化，處理時間節省為1.48-1.52，提升了約30%。由于charAt()和length()的内部實作都挺簡單的，是以提升的性能不太明顯。
另外補充一下，經網友回報，在JDK 1.6上，filter3和filter2的性能基本相同。可能是由于JDK 1.6已經進行了相關的優化。
◇版本4
然後看看filter4，代碼如下：
private static String filter4(String strOld)
{
int nLen = strOld.length();
StringBuffer strNew = new StringBuffer(nLen);
for(int i=0; i<nLen; i++)
{
char ch = strOld.charAt(i);
if('0'<=ch && ch<='9')
{
strNew.append(ch);
}
}
return strNew.toString();
}
filter4和filter3差别也很小，唯一差别就在于調用了StringBuffer帶參數的構造函數。通過StringBuffer的構造函數設定初始的容量大小，可以有效避免append()追加字元時重新配置設定記憶體，進而提高性能。
filter4的處理時間大約在1.33-1.39秒。約提高10%，可惜提升的幅度有點小 :-(
◇版本5
最後來看看終極版本，性能最好的filter5。
private static String filter5(String strOld)
{
int nLen = strOld.length();
char[] chArray = new char[nLen];
int nPos = 0;
for(int i=0; i<nLen; i++)
{
char ch = strOld.charAt(i);
if('0'<=ch && ch<='9')
{
chArray[nPos] = ch;
nPos++;
}
}
return new String(chArray, 0, nPos);
}
猛一看，你可能會想：filter5和前幾個版本的差别也忒大了吧！filter5既沒有用String也沒有用StringBuffer，而是拿字元數組進行中間處理。
filter5的處理時間，隻用了0.72-0.78秒，相對于filter4提升了将近50%。為啥捏？是不是因為直接操作字元數組，節省了append(char)的調用？通過檢視append(char)的源代碼，内部的實作很簡單，應該不至于提升這麼多。
那是什麼原因捏？
首先，雖然filter5有一個字元數組的建立開銷，但是相對于filter4來說，StringBuffer的構造函數内部也會有字元數組的建立開 銷。兩相抵消。是以filter5比filter4還多節省了StringBuffer對象本身的建立開銷。（在我的JDK 1.5環境中，這個因素比較明顯）
其次，由于StringBuffer是線程安全的（它的方法都是synchronized），是以調用它的方法有一定的同步開銷，而字元數組則沒有，這又是一個性能提升的地方。（經網友回報，此因素在JDK 1.6中比較明顯）
基于上述兩個因素，是以filter5比filter4又有較大幅度的提升。
★對于5個版本的總結
上述5個版本，filter1和filter5的性能相差約12倍（已經超過一個數量級）。除了filter3相對于filter2是通過消除函數重複 調用來提升性能，其它的幾個版本都是通過節省記憶體配置設定，降低了時間開銷。可見記憶體配置設定對于性能的影響有多大啊！如果你是看了上一個文章 才寫出filter4或者filter5，那說明你已經領會了個中奧妙，我那個文章也就沒白寫了。
★一點補充說明，關于時間和空間的平衡
另外，需要補充說明一下。版本4和版本5使用了空間換時間的手法來提升性能。假如被過濾的字元串很大 ，并且數字字元的比例很低 ，這種方式就不太合算了。
舉個例子：被處理的字元串中，絕大部分都隻含有不到10%的數字字元，隻有少數字元串包含較多的數字字元。這時候該怎麼辦捏？對于filter4來說， 可以把new StringBuffer(nLen);修改為new StringBuffer(nLen/10);來節約空間開銷。但是filter5就沒法這麼玩了。
是以，具體該用版本4還是版本5，要看具體情況了。隻有在你非常 看重時間開銷，且數字字元比例很高（至少大于50%）的情況下，用filter5才合算。否則的話，建議用filter4。
下一個文章，打算介紹一下“關于垃圾回收（GC） ”的話題。
版權聲明
本部落格所有的原創文章，作者皆保留版權。轉載必須包含本聲明，保持本文完整，并以超連結形式注明作者程式設計随想 和本文原始位址：
http://program-think.blogspot.com/2009/03/java-performance-tuning-2-string.html
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)