那么為什么StringBuilder的性能比StringBuffer的高呢？這 則與線程安全有關。如果你讀過《Think in Java》，而且對里面描述HashTable和HashMap區別的那部分章節比較熟悉的話，你一定也明白了原因所在。對，就是支持線程同步保證線程安 全而導致性能下降的問題。HashTable是線程安全的，很多方法都是synchronized方法，而HashMap不是線程安全的，但其在單線程程 序中的性能比HashTable要高。StringBuffer和StringBuilder類的區別也在于此，新引入的StringBuilder類不 是線程安全的，但其在單線程中的性能比StringBuffer高。

String str="You are nice.";
str+="I love you so much.";

如果用StringBuffer類的話，代碼如下：

StringBuffer str= new StringBuffer("You are nice.");
str.append("I love you so much.");

從表面看來String類只用一個加號（+）便完成了字符串的拼接，而StringBuffer類卻要調用一個append()方法，是否實現起來更簡潔，更單純呢？其實不然，讓我們了解一下程序運行內部發生了哪些事情：Struts與Struts2的區別

經編譯后程序的bytecode（字節碼）展示出了實質： 在用String類對象直接拼接時，JVM會創建一個臨時的StringBuffer類對象，并調用其append()方法完成字符串的拼接，這是因為 String類是不可變的，拼接操作不得不使用StringBuffer類（并且－－JVM會將"You are nice."和"I love you so much."創建為兩個新的String對象）。之后，再將這個臨時StringBuffer對象轉型為一個String，代價不菲！可見，在這一個簡單 的一次拼接過程中，我們讓程序創建了四個對象：兩個待拼接的String，一個臨時StringBuffer，和最后將StringBuffer轉型成為 的String－－它當然不是最初的str了，這個引用的名稱沒變，但它指向了新的String對象。

而如果直接使用StringBuffer類，程序將只產生兩個對象：最初的StringBuffer和拼接時的String（"I love you so much."），也不再需要創建臨時的StringBuffer類對象而后還得將其轉換回String對象。

可以想象，當我們的字符串要被循環拼接若干段時，用String類直接操作會帶來多少額外的系統開銷，生成多少無用的臨時StringBuffer對象，并處理多少次無謂的強制類型轉換哪。