StringBuffer已過時？

在這本書中「有效的Java」，喬希布洛赫說StringBuffer已過時？

StringBuffer的主要是過時的，應該由非同步實施「的StringBuilder」

所取代。

但以我的經驗，我仍然看到了StringBuffer類的廣泛使用。爲什麼StringBuffer類現在已經過時，爲什麼StringBuilder比StringBuffer更受歡迎，除了由於非同步而提高性能？

2011-07-21 Varun Achar

由於同樣的原因，你會看到StringBuffer被廣泛使用，你仍然可以看到Vector類被廣泛使用，即1.人們閱讀Java 1.5之前的書籍。 2.你仍然可以在網上找到很多使用StringBuffer的例子。 3.仍然有人編程/教Java，但不知道StringBuilder。 – helpermethod

這是過時的新的代碼上的Java 1.5一般應使用StringBuilder - 這是非常罕見你真的需要一個線程安全的方式來構建字符串，那麼爲什麼付出同步成本是多少？

我懷疑代碼，您看到使用StringBuffer大多落入水桶：寫保持與舊的JDK兼容性編寫的Java 1.5之前

寫的人不知道是誰做StringBuilder
通過自動生成工具不知道StringBuilder

來源

2011-07-21 11:08:17

+20

我經歷了StringBuffer和StringBuilder的代碼。除了StringBuffer的所有方法都附加了synchronized關鍵字之外，它們完全相同。 –

@Varun：那根本就不會讓我感到意外。 –

我懷疑有很多瞭解StringBuilder的人會因爲純粹的習慣而繼續使用StringBuffer。我知道我必須去爭取它...... –

並非所有人都像你一樣廣泛地閱讀:-)

我只是半開玩笑。人們總是複製代碼和模式。許多人不會與API更改保持聯繫。

爲什麼StringBuffer過時？因爲在絕大多數情況下，其同步行爲不是必需的。我想不出我曾經需要它的時間。儘管同步現在不是它曾經的性能問題，但在沒有必要的情況下交納稅款是沒有意義的。

來源

2011-07-21 11:05:51

爲什麼StringBuffer類現在已經過時了？

因爲它的操作是同步的，這增加了開銷，很少有用。

之所以你仍然可以看到普遍使用StringBuffer僅僅是慣性：還有數不清的代碼實例教程在那裏，一直沒有更新，使用StringBuilder，大家還在學習這些污染源的過時的做法（不只是這一個）。即使是那些更瞭解情況的人也往往會迴歸舊習慣。

來源

2011-07-21 11:10:43

不僅在大多數情況下不需要同步，如果您仍然使用它，它實際上會爲您的代碼的讀者提供錯誤信息：即，讀者可能會被認爲需要同步，但實際上並不需要同步。

使用StringBuilder而不是廣告宣稱您不期望跨線程訪問這一事實。

事實上，跨線程發送數據幾乎總是要通過定義良好的通信通道完成，而不是簡單地通過訪問同步的字符串緩衝區。所以在某種程度上，我會推薦使用總是使用不同的解決方案，即使在乍一看StringBuffer似乎是適當的。

來源

2011-07-21 14:13:48

我認爲過時是誇大其詞。

StringBuffer已同步。 StringBuilder不是。

在很多（也許是大多數情況下），你不會關心用於構建字符串的東西的線程安全性。在這些情況下你應該使用StringBuilder。然而，在的一些的情況下，您可能很想確保對象上的操作是線程安全的。在這些情況下，StringBuffer仍然有用。

來源

2011-07-21 17:06:22

不確定如果你關心結果字符串中數據的順序，我可以想出一個很好的理由讓多個線程構建一個字符串。 – Hardwareguy

@Hardwareguy：我猜想某種記錄器，因爲你可以通過附加一個完整的消息來工作。雖然會很麻煩，而且Code Code Smell也很差。 –

StringBuffer已過時？

回答

相關問題