stringbuffer线程安全但性能低，因所有修改方法加synchronized锁住this实例，导致高并发下锁竞争严重；stringbuilder无同步，单线程性能更优；线程安全不等于业务逻辑安全。

高并发下用 StringBuffer 并不天然“安全又高效”，它只是线程安全，但性能会明显拖慢——同步锁是瓶颈，不是保障。真正需要的是根据共享范围、操作粒度和并发强度做精准判断，而不是默认选 StringBuffer。

StringBuffer 的同步到底锁住了什么

StringBuffer 所有修改方法（append、insert、delete、reverse）都加了 synchronized，锁的是当前实例对象（this）。这意味着：

• 同一时刻，只有一个线程能执行它的任意一个同步方法
• 多个线程调用不同方法（比如一个 append，一个 delete）也会排队等待
• toString() 虽然也同步，但返回的是新 String 对象，后续对该 String 的操作不再受锁保护

高并发场景下 StringBuffer 的真实开销

在 JDK 17、8 核 CPU 下做 100 万次 append 测试，StringBuffer 比 StringBuilder 慢约 2–3 倍；当并发线程数超过 4，吞吐量增长几乎停滞，CPU 大量时间花在锁竞争和线程阻塞上。这不是“稍慢”，而是可测量的性能拐点。

更关键的是：单个方法同步 ≠ 业务逻辑安全。例如判断长度再追加，两步之间存在竞态窗口：

❌ 错误写法

if (buf.length()

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

✅ 正确做法

必须显式同步整个逻辑块：synchronized (buf) { if (buf.length()

比 StringBuffer 更适合高并发的替代方案

多数高并发字符串拼接场景，其实不需要共享可变缓冲区。更优解往往更轻量：

• ThreadLocal：每个线程独享实例，零锁开销，复用率高，适用于日志格式化、SQL 构建等典型场景
• 不可变拼接 + 并发收集：用 ConcurrentLinkedQueue 或 CopyOnWriteArrayList 收集片段，最后由单一线程合并，适合异步聚合类任务
• 预分配容量 + StringBuilder：已知最终长度时，new StringBuilder(estimatedSize)，避免扩容抖动，单线程内极致高效

什么时候才真该用 StringBuffer

仅限以下三类情况之一成立时：

• 多个线程长期共享同一个 StringBuffer 实例，并频繁并发修改（如老系统中全局日志缓冲器）
• 无法重构为无状态设计，且已有代码强依赖其 synchronized 语义
• 并发写入频率极低（如每秒几次），但要求绝对线程安全，且不愿引入额外结构

其余所有情况——包括局部变量拼接、接口响应组装、循环内构建——都应优先用 StringBuilder 或 ThreadLocal 方案。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南