为什么StringBuffer效率低

实际上，StringBuffer 的效率并不低，只是在某些场景下看起来比 StringBuilder 慢。常见说法是“StringBuffer 效率低”，主要原因在于线程安全带来的额外开销。

下面分点说明：

1. StringBuffer 是线程安全的

StringBuffer 的大部分方法都使用了 synchronized 修饰，例如：

public synchronized StringBuffer append(String str) {
    ...
}

代价：

• 每次调用方法都要进行锁的获取和释放
• 即使只有一个线程在使用，也会走同步逻辑
• 在多线程竞争时还会有锁竞争、上下文切换等开销

而 StringBuilder 没有 synchronized，所以在单线程下更快。

2. 单线程场景下 StringBuilder 更快

在 99% 的实际业务代码中（如方法内部拼接字符串）：

StringBuilder sb = new StringBuilder();
sb.append("a").append("b");

这里：

• 不存在多线程共享
• 不需要同步
• StringBuilder 少了锁开销 → 更快

所以 “StringBuffer 效率低”通常是相对于 StringBuilder 而言的。

3. 与 String 拼接相比，StringBuffer 并不慢

很多人误以为 StringBuffer 慢，其实：

String s = "a" + "b" + "c";

在编译后可能等价于：

String s = new StringBuilder().append("a").append("b").append("c").toString();

而如果是循环中拼接 String：

String s = "";
for (...) {
    s += x; // 每次都新建 String 对象，非常慢
}

这时 StringBuffer / StringBuilder 明显更快。

4. 真正“慢”的来源不是 StringBuffer 本身

可能的慢点包括：

• 不必要的同步（用 StringBuffer 但只有单线程）
• 频繁创建 StringBuffer 对象
• 初始容量设置不合理，导致数组扩容

例如：

new StringBuffer().append(...) // 默认容量 16，容易扩容

5. 总结一句话

StringBuffer 不是效率低，而是“为了保证线程安全付出了性能代价”。

使用建议：

• ✅ 单线程 → 用 StringBuilder（更快）
• ✅ 多线程共享且需要安全 → 用 StringBuffer
• ❌ 不要在单线程里为了“保险”用 StringBuffer

如果你愿意，我也可以从 JVM 实现 / 字节码层面 或 性能对比实验 来进一步说明。