StringBuffer 的线程安全依赖方法级 synchronized，但带来显著性能开销：单线程仍执行 monitor 指令、内存屏障及锁状态判断；粗粒度锁阻塞无关操作；toStringCache 增加同步负担；相比 StringBuilder，单线程快 10%–15%，低竞争多线程可达 5 倍差距；选型应基于真实共享与竞争模式，而非仅线程数量。

StringBuffer 的线程安全靠的是方法级 synchronized，但它不是“免费的午餐”——锁带来安全，也拖慢速度。单线程下它照样要走完整锁流程，而多线程低竞争时，开销反而更显眼。

同步锁的真实成本不止是“排队”

很多人以为 synchronized 只在多线程争抢时才有代价，其实不然：

• JVM 每次调用 synchronized 方法，都要执行 monitor enter/exit，哪怕当前只有 1 个线程
• 必须插入内存屏障（memory barrier），保证字段修改对其他线程可见——这会抑制指令重排序，影响 CPU 流水线效率
• 即使没竞争，偏向锁也可能被撤销、轻量级锁可能膨胀为重量级锁，这些判断逻辑照常运行
• toString() 还要维护 toStringCache，而这个缓存本身也要被同步保护，进一步增加路径复杂度

粗粒度锁限制了并发潜力

StringBuffer 几乎所有 public 方法（append、insert、delete、reverse、length、toString）都加了 synchronized，且锁对象是 this：

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 一次 append 就得独占整个 StringBuffer 实例，哪怕另一个线程只想读 length 或调用不冲突的 charAt，也得等
• 无法按需锁定内部 char[] 的某一段，比如只锁写入区域，而是“全有或全无”
• 链式调用如 sb.append("a").append("b").append("c") 会反复进出锁，三次 monitor 操作叠加开销

与 StringBuilder 的差距不只是“有没有锁”

两者共用 AbstractStringBuilder 底层，差异集中在同步层：

立即学习“Java免费学习笔记（深入）”；

• StringBuilder 所有方法都是普通 invokevirtual，无 monitor 指令，无锁检查，无缓存一致性维护
• toString() 直接复制数组，看似多一次 copy，实则省去了锁+缓存校验的综合成本
• 实测显示：单线程高频拼接场景，StringBuilder 通常快 10%–15%；高并发但无实际竞争时，性能差距可达 5 倍

选型不能只看“是否多线程”，要看真实竞争模式

线程安全 ≠ 必须用 StringBuffer：

• 若 StringBuffer 实例仅被单一线程持有（如局部变量、RequestScope Bean），用 StringBuilder 更合理
• 若多个线程共享同一实例，且存在写操作竞争，才真正需要 StringBuffer 的同步保障
• 若需更高并发吞吐，可考虑无锁方案（如 ThreadLocal）或更现代的并发容器（如 ConcurrentLinkedQueue 配合字符缓冲）