那么為什么StringBuilder的性能比StringBuffer的高呢？這 則與線程安全有關(guān)。如果你讀過《Think in Java》，而且對里面描述HashTable和HashMap區(qū)別的那部分章節(jié)比較熟悉的話，你一定也明白了原因所在。對，就是支持線程同步保證線程安 全而導(dǎo)致性能下降的問題。HashTable是線程安全的，很多方法都是synchronized方法，而HashMap不是線程安全的，但其在單線程程 序中的性能比HashTable要高。StringBuffer和StringBuilder類的區(qū)別也在于此，新引入的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類只用一個(gè)加號（+）便完成了字符串的拼接，而StringBuffer類卻要調(diào)用一個(gè)append()方法，是否實(shí)現(xiàn)起來更簡潔，更單純呢？其實(shí)不然，讓我們了解一下程序運(yùn)行內(nèi)部發(fā)生了哪些事情：Struts與Struts2的區(qū)別

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

而如果直接使用StringBuffer類，程序?qū)⒅划a(chǎn)生兩個(gè)對象：最初的StringBuffer和拼接時(shí)的String（"I love you so much."），也不再需要?jiǎng)?chuàng)建臨時(shí)的StringBuffer類對象而后還得將其轉(zhuǎn)換回String對象。

可以想象，當(dāng)我們的字符串要被循環(huán)拼接若干段時(shí)，用String類直接操作會帶來多少額外的系統(tǒng)開銷，生成多少無用的臨時(shí)StringBuffer對象，并處理多少次無謂的強(qiáng)制類型轉(zhuǎn)換哪。