★一個簡單的需求

　　首先描述一下需求：
給定一個 String 對象，過濾掉除了數字（字符‘0‘到‘9‘）以外的其它字符。要求時間開銷盡可能小。過濾函數的原型如下：

String filter(String str);

　　針對上述需求，俺寫了5個不同的過濾函數。為了敘述方便，函數名分別定為 filter1 到 filter5。其中 filter1 性能最差、filter5 性能最好。在看後續的內容之前，你先暗自思考一下，如果由你來實現該函數，大概會寫成什麽樣？最好把你想好的函數寫下來，便於跟俺給出的例子作對比。

★代碼——循序漸進的5種實現方式

◇測試代碼

　　為了方便測試性能，先準備好一坨測試代碼，具體如下：

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，使用的測試字符串是隨機生成的，長度32個 char，只含字母和數字。由於 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 的代碼。
　　有些同學可能會問：為啥不用 StringBuilder？
　　確實，在 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 是通過消除函數重復調用來提升性能，其它的幾個版本都是通過節省內存分配，降低了時間開銷。可見內存分配對於性能的影響有多大啊！

★一點補充說明，關於時間和空間的平衡

　　另外，需要補充說明一下。版本4和版本5使用了空間換時間的手法來提升性能。假如被過濾的字符串【很大】，並且數字字符的比例【很低】，這種方式就不太合算了。
　　舉個例子：被處理的字符串中，絕大部分都只含有不到10%的數字字符，只有少數字符串包含較多的數字字符。這時候該怎麽辦捏？
　　對於 filter4 來說，可以把 new StringBuffer(nLen); 修改為 new StringBuffer(nLen/10); 來節約空間開銷。但是 filter5 就沒法這麽玩了。
　　所以，具體該用“版本4”還是“版本5”，要看具體情況了。只有在你【非常】看重時間開銷，且數字字符比例很高（至少大於50%）的情況下，用 filter5 才合算。否則的話，建議用 filter4。

AJPFX淺談Java 性能優化之字符串過濾實戰