Java的StringBuilder在高效能場景下怎麼正確使用

StringBuilder在高性能場景下的正確用法

關於StringBuilder，一般同學只簡單記住了，字串拼接要用StringBuilder，不要用＋，也不要用StringBuffer，然後效能就是最好的了，真的嗎？

還有些同學，還聽過三句似是而非的經驗：

1. Java編譯優化後＋和StringBuilder的效果一樣；

2. StringBuilder不是線程安全的，為了「安全」起見最好還是用StringBuffer；

3. 永遠不要自己拼接日誌訊息的字串，交給slf4j來。

1. 初始長度好重要，值得說四次。

StringBuilder的內部有一個char[]， 不斷的append()就是不斷的往char[]裡填東西的過程。

new StringBuilder() 時char[]的預設長度是16，然後，如果要append第17個字符，怎麼辦？

用System.arraycopy倍增擴充擴充！ ！ ！ ！

這樣一來有陣列拷貝的成本，二來原來的char[]也白白浪費了要被GC掉。可以想見，一個129字元長度的字串，經過了16，32，64, 128四次的複製和丟棄，合共申請了496字元的數組，在高性能場景下，這幾乎不能忍。

所以，合理設定一個初始值多重要。

但如果我實在估算不好呢？多估一點點好了，只要字串最後大於16，就算浪費一點點，也比成倍的擴容好。

2. Liferay的StringBundler類別

Liferay的StringBundler類別提供了另一個長度設定的思路，它在append()的時候，不急著往char[]裡塞東西，而是先拿一個String[]把它們都存起來，到了最後才把所有String的length加起來，建構一個合理長度的StringBuilder。

3. 但，還是浪費了一倍的char[]

#浪費發生在最後一步，StringBuilder.toString()

// Create a copy , don't share the array
return new String(value, 0, count);

String的建構子會用System.arraycopy()複製一把傳入的char[]來確保安全性不可變性，如果故事就這樣結束，StringBuilder裡的char[]還是被白白犧牲了。

為了不浪費這些char[]，一種方法是用Unsafe之類的各種黑科技，繞過建構子直接給String的char[]屬性賦值，但很少人這樣做。

另一個可靠的方法就是重複使用StringBuilder。而重用，也解決了前面的長度設定問題，因為即使一開始估算不準，多擴容幾次之後也夠了。

4. 重複使用StringBuilder

這個做法來自JDK裡的BigDecimal類別（沒事看看JDK程式碼多重要），SpringSide裡將程式碼提取成StringBuilderHolder，裡面只有一個函數

public StringBuilder getStringBuilder() {
sb.setLength(0);
return sb;
}

StringBuilder.setLength()函數只重置它的count指針，而char[]則會繼續重用，而toString()時會把目前的count指針也當作參數傳給String的建構函數，所以不用擔心把超過新內容大小的舊內容也傳進去了。可見，StringBuilder是完全可以重複使用的。

為了避免併發衝突，這個Holder一般設為ThreadLocal，標準寫法見BigDecimal或StringBuilderHolder的註釋。

5. ＋ 與StringBuilder

String s ＝ “hello ” user.getName();

這句話經過javac編譯後的效果，的確等價於使用StringBuilder，但沒有設定長度。

String s ＝ new StringBuilder().append(“hello”).append(user.getName());

但是，如果像下面這樣：

String s ＝ “hello ”;
// 隔了其他一些語句
s = s ＋ user.getName();

#每一語句，都會產生一個新的StringBuilder，這裡就有了兩個StringBuilder，效能就完全不一樣了。如果是在循環體裡s =i; 就更加多到沒譜。

據R大說，努力的JVM工程師們在運行優化階段， 根據XX: OptimizeStringConcat(JDK7u40後默認打開)，把相鄰的(中間沒隔著控制語句) StringBuilder合成一個，也會努力的猜長度。

所以，保險起見還是繼續自己用StringBuilder並設定長度好了。

6. StringBuffer 與 StringBuilder

StringBuffer與StringBuilder都是繼承於AbstractStringBuilder，唯一的差別就是StringBuffer的函數上都有synchronized關鍵字。

那些說StringBuffer 「安全」的同學，其實你幾時看過幾個線程輪流append一個StringBuffer的狀況？ ？ ？

7. 永遠把日誌的字串拼接交給slf4j??

logger.info("Hello {}", user.getName());

#對於不知道要不要輸出的日誌，交給slf4j在真的需要輸出時才去拼接的確能省節約成本。

但對於一定要輸出的日誌，直接自己用StringBuilder拼接更快。因為看看slf4j的實現，其實就是不斷的indexof("{}"), 不斷的subString()，再不斷的用StringBuilder拼起來而已，沒有銀彈。

PS. slf4j中的StringBuilder在原始Message之外預留了50個字符，如果可變參數加起來長過50字符還是得複製擴容......而且StringBuilder也沒有重用。

以上是Java的StringBuilder在高效能場景下怎麼正確使用的詳細內容。更多資訊請關注PHP中文網其他相關文章！