java效能優化方案1——使用StringBuilder

1、使用StringBuilder
StingBuilder 應該是在我們的Java程式碼中預設使用的，應該避免使用 + 操作符。或許你會對 StringBuilder 的語法糖（syntax sugar）持有不同意見，比如：
1 String x = “a” + args.length + “b”;
將會被編譯為：
0 new java.lang.StringBuilder [16]
3 dup
4 ldc [18]
6 invokespecial java.lang.StringBuilder(java.lang.String) [20]
9 aload_0 [args]
10 arraylength
11 invokevirtual java.lang.StringBuilder.append(int) : java.lang.StringBuilder [23]
14 ldc [27]
16 invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [29]
19 invokevirtual java.lang.StringBuilder.toString() : java.lang.String [32]
22 astore_1 [x]
但究竟發生了什麼？接下來是否需要用下面的部分來對 String 進行改善呢？
String x = “a” + args.length + “b”;

if (args.length == 1)

x = x + args[0];

現在使用到了第二個 StringBuilder，而且這個 StringBuilder 不會消耗堆中額外的記憶體，但卻給 GC 帶來了壓力。
StringBuilder x = new StringBuilder(“a”);
x.append(args.length);
x.append(“b”);

if (args.length == 1);

x.append(args[0]);

小結
在上面的樣例中，如果你是依靠Java編譯器來隱式生成例項的話，那麼編譯的效果幾乎和是否使用了 StringBuilder 例項毫無關係。請記住：在 N.O.P.E 分支中，每次CPU的迴圈的時間到白白的耗費在GC或者為 StringBuilder 分配預設空間上了，我們是在浪費 N x O x P 時間。
一般來說，使用 StringBuilder 的效果要優於使用 + 操作符。如果可能的話請在需要跨多個方法傳遞引用的情況下選擇 StringBuilder，因為 String 要消耗額外的資源。JOOQ在生成複雜的SQL語句便使用了這樣的方式。在整個抽象語法樹（AST Abstract Syntax Tree）SQL傳遞過程中僅使用了一個 StringBuilder 。
更加悲劇的是，如果你仍在使用 StringBuffer 的話，那麼用 StringBuilder 代替 StringBuffer 吧，畢竟需要同步字串的情況真的不多。