StringBuffer 與 StringBuilder 深度解析：效能、線程安全與選型指南

核心差異速覽

底層原理深度剖析

可變字符序列機制

StringBuilder 和 StringBuffer 都是可變字符序列，內部維護一個字符數組。每次操作（append、insert 等）直接在該數組上修改，避免了 String 不可變特性導致的頻繁創建新對象、複製數組開銷。

擴容策略

兩者擴容邏輯一致：當容量不足時，新容量 = (舊容量 + 1) * 2。預設初始容量 16 字符。

線程安全實現差異

StringBuffer：同步鎖機制

// 核心方法均加 synchronized
public synchronized int length() { ... }
public synchronized StringBuffer append(String str) { ... }
public synchronized StringBuffer insert(int offset, String str) { ... }

每個公開方法都加 synchronized，確保多線程環境下操作原子性，但帶來鎖開銷。

StringBuilder：無鎖設計

// 無 synchronized 修飾
public int length() { ... }
public StringBuilder append(String str) { ... }

單線程下零鎖開銷，性能顯著優於 StringBuffer。

實戰選型決策樹

1. 多線程共享字符串緩衝區 → 必選 StringBuffer
2. 單線程或線程局部變量 → 首選 StringBuilder
3. 字符串拼接簡單場景 → 現代編譯器優化下，String + 自動轉為 StringBuilder，無需手動優化

常見誤區澄清

誤區：「String 操作大量數據用 String」

正確：大量拼接必須用 StringBuilder/StringBuffer，String 每次拼接都產生新對象，O(n²) 時間複雜度。

誤區：「StringBuffer 總是比 StringBuilder 安全」

正確：僅方法級同步，複合操作（如先檢查再追加）仍需外部同步。單線程用 StringBuffer 純屬性能浪費。

效能基準測試參考

// 單線程 100萬次 append
StringBuilder: ~15ms
StringBuffer:  ~45ms  (約 3 倍開銷)
String +:      ~12000ms (災難級)

總結建議

• 日常開發 95% 場景：StringBuilder
• 多線程共享緩衝區：StringBuffer
• 簡單拼接：信任編譯器優化，直接用 +
• API 設計：返回類型優先 String，內部用 StringBuilder