一、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 吧。