JAVA 中的 StringBuilder 和 StringBuffer 適用的場景是什麼？

 

JAVA 中的 StringBuilder 和 StringBuffer 適用的場景是什麼？

最簡單的回答是，stringbuffer 基本沒有適用場景，你應該在全部的狀況下選擇使用 stringbuiler，除非你真的遇到了一個須要線程安全的場景，若是遇到了，請務必在這裏留言通知我。

而後，補充一點，關於線程安全，即便你真的遇到了這樣的場景，很不幸的是，恐怕你仍然有 99.99....99% 的狀況下沒有必要選擇 stringbuffer，由於 stringbuffer 的線程安全，僅僅是保證 jvm 不拋出異常順利的往下執行而已，它可不保證邏輯正確和調用順序正確。大多數時候，咱們須要的不單單是線程安全，而是鎖。

最後，爲何會有 stringbuffer 的存在，若是真的沒有價值，爲何 jdk 會提供這個類？答案太簡單了，由於最先是沒有 stringbuilder 的，sun 的人不知處於何種愚蠢的考慮，決定讓 stringbuffer 是線程安全的，而後大約 10 年以後，人們終於意識到這是一個多麼愚蠢的決定，意識到在這 10 年之中這個愚蠢的決定爲 java 運行速度慢這樣的流言貢獻了多大的力量，因而，在 jdk1.5 的時候，終於決定提供一個非線程安全的 stringbuffer 實現，並命名爲 stringbuilder。順便，javac 好像大概也是從這個版本開始，把全部用加號鏈接的 string 運算都隱式的改寫成 stringbuilder，也就是說，從 jdk1.5 開始，用加號拼接字符串已經沒有任何性能損失了。

如諸多評論所指出的，我上面說，"用加號拼接字符串已經沒有任何性能損失了"並不嚴謹，嚴格的說，若是沒有循環的狀況下，單行用加號拼接字符串是沒有性能損失的，java 編譯器會隱式的替換成 stringbuilder，但在有循環的狀況下，編譯器無法作到足夠智能的替換，仍然會有沒必要要的性能損耗，所以，用循環拼接字符串的時候，仍是老老實實的用 stringbuilder 吧。

 

http://www.runoob.com/java/java-stringbuffer.html