java連接字符串有多種方式，比如+操作符， StringBuilder.append 方法，這些方法各有什么優(yōu)劣（可以適當(dāng)說明各種方式的實(shí)現(xiàn)細(xì)節(jié)）？
按照高效的原則，那么java中字符串連接的最佳實(shí)踐是什么？
有關(guān)字符串處理，都有哪些其他的最佳實(shí)踐？
廢話不多說，直接開始， 環(huán)境如下:
JDK版本: 1.8.0_65
CPU: i7 4790`
內(nèi)存: 16G
直接使用 + 拼接
看下面的代碼：
在上面的代碼中，我們使用加號(hào)來連接四個(gè)字符串，這種字符串拼接的方式優(yōu)點(diǎn)很明顯: 代碼簡(jiǎn)單直觀，但是對(duì)比 StringBuilder 和 StringBuffer 在 大部分情況下 比后者都低，這里說是 大部分情況下 ，我們用javap工具對(duì)上面代碼生成的字節(jié)碼進(jìn)行反編譯看看在編譯器對(duì)這段代碼做了什么。
從反編譯的結(jié)果來看，實(shí)際上對(duì)字符串使用 + 操作符進(jìn)行拼接，編譯器會(huì)在編譯階段把代碼優(yōu)化成使用 StringBuilder 類，并調(diào)用 append 方法進(jìn)行字符串拼接，最后調(diào)用 toString 方法，這樣看來是否可以認(rèn)為在一般情況下 其實(shí)直接使用+，反正編譯器也會(huì)幫我優(yōu)化為使用StringBuilder ？
StringBuilder 源碼分析
答案自然是 不可以 的，原因就在于 StringBuilder 這個(gè)類它內(nèi)部做了些什么時(shí)。
我們看一看 StringBuilder 類的構(gòu)造器
StringBuilder 提供了4個(gè)默認(rèn)的構(gòu)造器， 除了無參構(gòu)造函數(shù)外，還提供了另外3個(gè)重載版本，而內(nèi)部都調(diào)用父類的 super(int capacity) 構(gòu)造方法，它的父類是 AbstractStringBuilder ，構(gòu)造方法如下：
可以看到實(shí)際上StringBuilder內(nèi)部使用的是 char數(shù)組 來存儲(chǔ)數(shù)據(jù)(String、StringBuffer也是)，這里 capacity 的值指定了數(shù)組的大小。結(jié)合 StringBuilder 的無參構(gòu)造函數(shù)，可以知道默認(rèn)的大小是 16 個(gè)字符。
也就是說如果待拼接的字符串總長(zhǎng)度不小于16的字符的話，那么其實(shí)直接拼接和我們手動(dòng)寫StringBuilder區(qū)別不大，但是我們自己構(gòu)造StringBuilder類可以指定數(shù)組的大小，避免分配過多的內(nèi)存。
現(xiàn)在我們?cè)倏纯?StringBuilder.append 方法內(nèi)部做了什么事：
直接調(diào)用的父類的 append方法 ：
在這個(gè)方法內(nèi)部調(diào)用了 ensureCapacityInternal 方法，當(dāng)拼接后的字符串總大小大于內(nèi)部數(shù)組 value 的大小時(shí)，就必須先擴(kuò)容才能拼接，擴(kuò)容的代碼如下：
StringBuilder 在擴(kuò)容時(shí)把容量增大到 當(dāng)前容量的兩倍+2 ，這是很可怕的，如果在構(gòu)造的時(shí)候沒有指定容量，那么很有可能在擴(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 方法來復(fù)制，這是一個(gè)native方法，底層直接操作內(nèi)存，所以比我們用循環(huán)來復(fù)制要塊的多，即便如此，大量申請(qǐng)內(nèi)存空間和復(fù)制數(shù)據(jù)帶來的影響也不可忽視。
使用 + 拼接和使用 StringBuilder 比較
上面這段代碼經(jīng)過優(yōu)化后相當(dāng)于：
一眼就能看出 創(chuàng)建了太多的StringBuilder對(duì)象 ，而且在每次循環(huán)過后str越來越大，導(dǎo)致每次申請(qǐng)的內(nèi)存空間越來越大，并且當(dāng)str長(zhǎng)度大于16時(shí)，每次都要擴(kuò)容兩次！而實(shí)際上 toString 方法在創(chuàng)建 String 對(duì)象時(shí)，調(diào)用了 Arrays.copyOfRange方法來復(fù)制數(shù)據(jù)，此時(shí)相當(dāng)于每執(zhí)行一次，擴(kuò)容了兩次，復(fù)制了3次數(shù)據(jù)，這樣的代價(jià)是相當(dāng)高的。
這段代碼的執(zhí)行時(shí)間在我的機(jī)器上都是0ms(小于1ms)和1ms，而上面那段代碼則大約在380ms！效率的差距相當(dāng)明顯。
同樣是上面的代碼，將循環(huán)次數(shù)調(diào)整為 1000000 時(shí)，在我的機(jī)器上，有指定 capacity 時(shí)耗時(shí)大約20ms，沒有指定 capacity 時(shí)耗時(shí)大約29ms，這個(gè)差距雖然和直接使用 + 操作符有了很大的提升(且循環(huán)次數(shù)增大了100倍)，但是它依舊會(huì)觸發(fā)多次擴(kuò)容和復(fù)制。
將上面的代碼改成使用 StringBuffer ，在我的機(jī)器上，耗時(shí)大約為33ms，這是因?yàn)?StringBuffer 在大部分方法上都加上了 synchronized 關(guān)鍵字來保證線程安全，執(zhí)行效率有一定程度上的降低。
使用 String.concat 拼接
現(xiàn)在再看這段代碼:
這段代碼使用了 String.concat 方法，在我的機(jī)器上，執(zhí)行時(shí)間大約為130ms，雖然直接相加要好的多，但是比起使用 StringBuilder 還要太多了，似乎沒什么用。其實(shí)并不是，在很多時(shí)候，我們只需要連接兩個(gè)字符串，而不是多個(gè)字符串的拼接，這個(gè)時(shí)候使用 String.concat 方法比 StringBuilder 要簡(jiǎn)潔且效率要高。
上面這段是 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ù)。
結(jié)論
現(xiàn)在根據(jù)上面的分析和測(cè)試可以知道：
Java中字符串拼接不要直接使用 + 拼接。
使用StringBuilder或者StringBuffer時(shí)，盡可能準(zhǔn)確地估算capacity，并在構(gòu)造時(shí)指定，避免內(nèi)存浪費(fèi)和頻繁的擴(kuò)容及復(fù)制。
在沒有線程安全問題時(shí)使用 StringBuilder ， 否則使用 StringBuffer 。
兩個(gè)字符串拼接直接調(diào)用 String.concat 性能最好。
關(guān)于 String 的其他最佳實(shí)踐：
用 equals 時(shí)總是把能確定不為空的變量寫在左邊，如使用 ''.equals(str) 判斷空串，避免空指針異常。
第二點(diǎn)是用來排擠第一點(diǎn)的.. 使用 str != null && str.length() != 0 來判斷空串，效率比第一點(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í)想的起來的就這么幾個(gè)了.. 請(qǐng)大家?guī)兔ρa(bǔ)充補(bǔ)充...
