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

FrankYou發表於2018-10-22

轉載:《StringBuilder在高效能場景下的正確用法》 by 江南白衣 

 

關於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()

 

//建立拷貝, 不共享陣列
return new String(value, 0, count);

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

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

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

 

4. 重用StringBuilder

這個做法來源於JDK裡的BigDecimal類(沒事看看JDK程式碼多重要),後來發現Netty也同樣使用。SpringSide裡將程式碼提取成StringBuilderHolder,裡面只有一個函式

 

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

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

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

不過,如果String的長度不大,那從ThreadLocal裡取一次值的代價還更大的多,所以也不能把這個ThreadLocalStringBuilder搞出來後,見到StringBuilder就替換。。。
 

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也沒有重用。

 

8. 小結

StringBuilder預設的寫法,會為129長度的字串拼接,合共申請625字元的陣列。所以高效能的場景下,永遠要考慮用一個ThreadLocal 可重用的StringBuilder。而且重用之後,就不用再玩猜長度的遊戲了。當然,如果字串只有一百幾十位元組,也不一定要考慮重用,設好初始值就好。

相關文章