摘要：兩個(gè)字符串拼接直接調(diào)用性能最好。關(guān)于的其他最佳實(shí)踐用時(shí)總是把能確定不為空的變量寫(xiě)在左邊，如使用判斷空串，避免空指針異常。在需要把其他對(duì)象轉(zhuǎn)換為字符串對(duì)象時(shí)，使用而不是直接調(diào)用方法，因?yàn)榍罢咭呀?jīng)對(duì)空值進(jìn)行檢測(cè)了，不會(huì)拋出空指針異常。

本文來(lái)源于問(wèn)題 Java字符串連接最佳實(shí)踐？

java連接字符串有多種方式，比如+操作符，StringBuilder.append方法，這些方法各有什么優(yōu)劣（可以適當(dāng)說(shuō)明各種方式的實(shí)現(xiàn)細(xì)節(jié)）？
按照高效的原則，那么java中字符串連接的最佳實(shí)踐是什么？
有關(guān)字符串處理，都有哪些其他的最佳實(shí)踐？

廢話不多說(shuō)，直接開(kāi)始， 環(huán)境如下:

JDK版本: 1.8.0_65
CPU: i7 4790
內(nèi)存: 16G

看下面的代碼：

    @Test
    public void test() {
        String str1 = "abc";
        String str2 = "def";
        logger.debug(str1 + str2);
    }

在上面的代碼中，我們使用加號(hào)來(lái)連接四個(gè)字符串，這種字符串拼接的方式優(yōu)點(diǎn)很明顯: 代碼簡(jiǎn)單直觀，但是對(duì)比StringBuilder和StringBuffer在大部分情況下比后者都低，這里說(shuō)是大部分情況下，我們用javap工具對(duì)上面代碼生成的字節(jié)碼進(jìn)行反編譯看看在編譯器對(duì)這段代碼做了什么。

public void test();
    Code:
       0: ldc           #5                  // String abc
       2: astore_1
       3: ldc           #6                  // String def
       5: astore_2
       6: aload_0
       7: getfield      #4                  // Field logger:Lorg/slf4j/Logger;
      10: new           #7                  // class java/lang/StringBuilder
      13: dup
      14: invokespecial #8                  // Method java/lang/StringBuilder."":()V
      17: aload_1
      18: invokevirtual #9                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      21: aload_2
      22: invokevirtual #9                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      25: invokevirtual #10                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
      28: invokeinterface #11,  2           // InterfaceMethod org/slf4j/Logger.debug:(Ljava/lang/String;)V
      33: return

從反編譯的結(jié)果來(lái)看，實(shí)際上對(duì)字符串使用+操作符進(jìn)行拼接，編譯器會(huì)在編譯階段把代碼優(yōu)化成使用StringBuilder類，并調(diào)用append方法進(jìn)行字符串拼接，最后調(diào)用toString方法，這樣看來(lái)是否可以認(rèn)為在一般情況下其實(shí)直接使用+，反正編譯器也會(huì)幫我優(yōu)化為使用StringBuilder？

答案自然是不可以的，原因就在于StringBuilder這個(gè)類它內(nèi)部做了些什么時(shí)。
我們看一看StringBuilder類的構(gòu)造器

    public StringBuilder() {
        super(16);
    }

    public StringBuilder(int capacity) {
        super(capacity);
    }

    public StringBuilder(String str) {
        super(str.length() + 16);
        append(str);
    }

    public StringBuilder(CharSequence seq) {
        this(seq.length() + 16);
        append(seq);
    }

StringBuilder提供了4個(gè)默認(rèn)的構(gòu)造器， 除了無(wú)參構(gòu)造函數(shù)外，還提供了另外3個(gè)重載版本，而內(nèi)部都調(diào)用父類的super(int capacity)構(gòu)造方法，它的父類是AbstractStringBuilder，構(gòu)造方法如下：

    AbstractStringBuilder(int capacity) {
        value = new char[capacity];
    }

可以看到實(shí)際上StringBuilder內(nèi)部使用的是char數(shù)組來(lái)存儲(chǔ)數(shù)據(jù)(String、StringBuffer也是)，這里capacity的值指定了數(shù)組的大小。結(jié)合StringBuilder的無(wú)參構(gòu)造函數(shù)，可以知道默認(rèn)的大小是16個(gè)字符。
也就是說(shuō)如果待拼接的字符串總長(zhǎng)度不小于16的字符的話，那么其實(shí)直接拼接和我們手動(dòng)寫(xiě)StringBuilder區(qū)別不大，但是我們自己構(gòu)造StringBuilder類可以指定數(shù)組的大小，避免分配過(guò)多的內(nèi)存。

現(xiàn)在我們?cè)倏纯?b>StringBuilder.append方法內(nèi)部做了什么事：

    @Override
    public StringBuilder append(String str) {
        super.append(str);
        return this;
    }

直接調(diào)用的父類的append方法：

    public AbstractStringBuilder append(String str) {
        if (str == null)
            return appendNull();
        int len = str.length();
        ensureCapacityInternal(count + len);
        str.getChars(0, len, value, count);
        count += len;
        return this;
    }

在這個(gè)方法內(nèi)部調(diào)用了ensureCapacityInternal方法，當(dāng)拼接后的字符串總大小大于內(nèi)部數(shù)組value的大小時(shí)，就必須先擴(kuò)容才能拼接，擴(kuò)容的代碼如下：

    void expandCapacity(int minimumCapacity) {
        int newCapacity = value.length * 2 + 2;
        if (newCapacity - minimumCapacity < 0)
            newCapacity = minimumCapacity;
        if (newCapacity < 0) {
            if (minimumCapacity < 0) // overflow
                throw new OutOfMemoryError();
            newCapacity = Integer.MAX_VALUE;
        }
        value = Arrays.copyOf(value, newCapacity);
    }

StringBuilder在擴(kuò)容時(shí)把容量增大到當(dāng)前容量的兩倍+2，這是很可怕的，如果在構(gòu)造的時(shí)候沒(méi)有指定容量，那么很有可能在擴(kuò)容之后占用了浪費(fèi)大量的內(nèi)存空間。其次擴(kuò)容后還調(diào)用了Arrays.copyOf方法，這個(gè)方法把擴(kuò)容前的數(shù)據(jù)復(fù)制到擴(kuò)容后的空間內(nèi)，這樣做的原因是：StringBuilder內(nèi)部使用char數(shù)組存放數(shù)據(jù)，java的數(shù)組是不可擴(kuò)容的，所以只能重新申請(qǐng)一片內(nèi)存空間，并把已有的數(shù)據(jù)復(fù)制到新的空間去，這里它最終調(diào)用了System.arraycopy方法來(lái)復(fù)制，這是一個(gè)native方法，底層直接操作內(nèi)存，所以比我們用循環(huán)來(lái)復(fù)制要塊的多，即便如此，大量申請(qǐng)內(nèi)存空間和復(fù)制數(shù)據(jù)帶來(lái)的影響也不可忽視。

    @Test
    public void test() {
        String str = "";
        for (int i = 0; i < 10000; i++) {
            str += "asjdkla";
        }
    }

上面這段代碼經(jīng)過(guò)優(yōu)化后相當(dāng)于：

    @Test
    public void test() {
        String str = null;
        for (int i = 0; i < 10000; i++) {
            str = new StringBuilder().append(str).append("asjdkla").toString();
        }
    }

一眼就能看出創(chuàng)建了太多的StringBuilder對(duì)象，而且在每次循環(huán)過(guò)后str越來(lái)越大，導(dǎo)致每次申請(qǐng)的內(nèi)存空間越來(lái)越大，并且當(dāng)str長(zhǎng)度大于16時(shí)，每次都要擴(kuò)容兩次！而實(shí)際上toString方法在創(chuàng)建String對(duì)象時(shí)，調(diào)用了Arrays.copyOfRange方法來(lái)復(fù)制數(shù)據(jù)，此時(shí)相當(dāng)于每執(zhí)行一次，擴(kuò)容了兩次，復(fù)制了3次數(shù)據(jù)，這樣的代價(jià)是相當(dāng)高的。

    public void test() {
        StringBuilder sb = new StringBuilder("asjdkla".length() * 10000);
        for (int i = 0; i < 10000; i++) {
            sb.append("asjdkla");
        }
        String str = sb.toString();
    }

這段代碼的執(zhí)行時(shí)間在我的機(jī)器上都是0ms(小于1ms)和1ms，而上面那段代碼則大約在380ms！效率的差距相當(dāng)明顯。

同樣是上面的代碼，將循環(huán)次數(shù)調(diào)整為1000000時(shí)，在我的機(jī)器上，有指定capacity時(shí)耗時(shí)大約20ms，沒(méi)有指定capacity時(shí)耗時(shí)大約29ms，這個(gè)差距雖然和直接使用+操作符有了很大的提升(且循環(huán)次數(shù)增大了100倍)，但是它依舊會(huì)觸發(fā)多次擴(kuò)容和復(fù)制。

將上面的代碼改成使用StringBuffer，在我的機(jī)器上，耗時(shí)大約為33ms，這是因?yàn)?b>StringBuffer在大部分方法上都加上了synchronized關(guān)鍵字來(lái)保證線程安全，執(zhí)行效率有一定程度上的降低。

現(xiàn)在再看這段代碼:

    @Test
    public void test() {
        String str = "";
        for (int i = 0; i < 10000; i++) {
            str.concat("asjdkla");
        }
    }

這段代碼使用了String.concat方法，在我的機(jī)器上，執(zhí)行時(shí)間大約為130ms，雖然直接相加要好的多，但是比起使用StringBuilder還要太多了，似乎沒(méi)什么用。其實(shí)并不是，在很多時(shí)候，我們只需要連接兩個(gè)字符串，而不是多個(gè)字符串的拼接，這個(gè)時(shí)候使用String.concat方法比StringBuilder要簡(jiǎn)潔且效率要高。

    public String concat(String str) {
        int otherLen = str.length();
        if (otherLen == 0) {
            return this;
        }
        int len = value.length;
        char buf[] = Arrays.copyOf(value, len + otherLen);
        str.getChars(buf, len);
        return new String(buf, true);
    }

上面這段是String.concat的源碼，在這個(gè)方法中，調(diào)用了一次Arrays.copyOf，并且指定了len + otherLen，相當(dāng)于分配了一次內(nèi)存空間，并分別從str1和str2各復(fù)制一次數(shù)據(jù)。而如果使用StringBuilder并指定capacity，相當(dāng)于分配一次內(nèi)存空間，并分別從str1和str2各復(fù)制一次數(shù)據(jù)，最后因?yàn)檎{(diào)用了toString方法，又復(fù)制了一次數(shù)據(jù)。

現(xiàn)在根據(jù)上面的分析和測(cè)試可以知道：

Java中字符串拼接不要直接使用+拼接。
使用StringBuilder或者StringBuffer時(shí)，盡可能準(zhǔn)確地估算capacity，并在構(gòu)造時(shí)指定，避免內(nèi)存浪費(fèi)和頻繁的擴(kuò)容及復(fù)制。
在沒(méi)有線程安全問(wèn)題時(shí)使用StringBuilder， 否則使用StringBuffer。
兩個(gè)字符串拼接直接調(diào)用String.concat性能最好。

用equals時(shí)總是把能確定不為空的變量寫(xiě)在左邊，如使用"".equals(str)判斷空串，避免空指針異常。
第二點(diǎn)是用來(lái)排擠第一點(diǎn)的.. 使用str != null && str.length() == 0來(lái)判斷空串，效率比第一點(diǎn)高。
在需要把其他對(duì)象轉(zhuǎn)換為字符串對(duì)象時(shí)，使用String.valueOf(obj)而不是直接調(diào)用obj.toString()方法，因?yàn)榍罢咭呀?jīng)對(duì)空值進(jìn)行檢測(cè)了，不會(huì)拋出空指針異常。
使用String.format()方法對(duì)字符串進(jìn)行格式化輸出。
在JDK 7及以上版本，可以在switch結(jié)構(gòu)中使用字符串了，所以對(duì)于較多的比較，使用switch代替if-else。
我暫時(shí)想的起來(lái)的就這么幾個(gè)了.. 請(qǐng)大家?guī)兔ρa(bǔ)充補(bǔ)充...