stringbuffer 的线程安全性真实有效但代价高昂：所有修改方法加 synchronized 锁，导致单线程性能下降约 85%，并发吞吐受限，仅在多线程共享实例且无法重构时才值得使用。

StringBuffer 的线程安全性是真实有效的，但它的代价很明确：用方法级 synchronized 锁住整个实例，换来的是多线程下数据不撕裂，牺牲的是单线程或低竞争场景下的执行效率。性能损耗不是“轻微拖慢”，而是结构性开销——它不只影响速度，还限制并发吞吐。

同步机制如何带来性能损耗

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

• 哪怕只是追加一个字符，也要获取并释放一次 monitor 锁，触发 JVM 层面的 monitorenter/monitorexit 指令
• 即使单线程运行，JIT 优化也无法完全消除无竞争同步的字节码开销和内存屏障成本
• length()、charAt() 这类读操作也被同步，无法真正并发，白白阻塞其他线程的只读访问
• 锁粒度粗，一次 append 就锁定整个对象，内部数组扩容、索引更新、字符拷贝全被串行化

实测性能差距有多明显

在典型单线程拼接场景中，StringBuffer 比 StringBuilder 明显更慢：

java-enterprise

Java企业开发专家，专注于Spring Boot、微服务架构和JVM优化。适用于：Java语言掌握、

下载

• 100 万次 append 操作（JDK 17），StringBuffer 耗时约 120ms，StringBuilder 约 65ms，慢约 85%
• 10 万次操作下，差距稳定在 10%–15%，说明同步开销随调用频次线性累积
• 若每次都在方法内新建实例（非复用），差距缩小至约 10%，但依然存在冗余锁初始化成本

什么情况下值得为线程安全买单

StringBuffer 的价值仅在满足以下全部条件时才成立：

• 多个线程共享同一个 StringBuffer 实例（非局部变量、非 ThreadLocal）
• 这些线程会并发调用修改方法（不只是读）
• 业务逻辑无法通过重构规避共享（例如不能把拼接移到单线程内完成）
• 没有更轻量替代方案（如用 ConcurrentHashMap 缓存中间结果，或用不可变字符串组合）

典型适用场景极少：全局日志缓冲器、配置中心动态模板拼接、遗留系统中无法解耦的跨线程字符串构建器。

更务实的平衡策略

与其纠结“怎么让 StringBuffer 更快”，不如优先绕开它的使用场景：

• 方法内拼接 → 声明为局部 StringBuilder，天然线程隔离，性能提升 50%–100%
• 需要预估长度 → 构造时指定容量（如 new StringBuilder(1024)），减少扩容拷贝
• 拼完再传递 → 用 toString() 转成 String 后传递，后续只读无需锁
• 多线程高频拼接 → 用 ThreadLocal<stringbuilder></stringbuilder>，避免共享与锁竞争
• 复合逻辑需原子性 → 单个 append 安全，但 if (sb.length() 不安全，必须手动 <code>synchronized(sb) 包裹

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