StringBuffer因所有公开方法加synchronized而比StringBuilder慢2–4倍，核心差异仅在于同步关键字，二者底层实现完全相同；线程安全仅在多线程共享同一实例时必要，局部使用应选StringBuilder，并预设容量以减少扩容开销。
因为 StringBuffer 的每个公开方法都加了 synchronized，而 StringBuilder 完全不加锁——同步机制本身就会带来锁获取、释放、内存屏障等开销，哪怕只有一个线程在跑，也绕不开。
核心差异就在一个关键字上
StringBuffer 和 StringBuilder 底层共享同一套实现（都继承自 AbstractStringBuilder），用的都是可变的 char[]（JDK9+ 改为 byte[]），扩容逻辑、append 行为、内部缓冲管理全都一样。唯一的区别是：StringBuffer 的 append()、toString()、delete() 等所有公共方法签名上都明确写了 synchronized；StringBuilder 则完全没这层修饰。
这意味着：
- 每次调用 StringBuffer 方法，JVM 都必须执行锁的进入与退出流程
- 即使当前线程是唯一使用者，也要承担锁的内存可见性保障成本
- JVM 对 synchronized 块会做更保守的优化，比如限制指令重排范围
性能差距不是“略慢”，而是实打实的开销
在单线程下做 10 万次 append("x")：
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- StringBuilder 通常耗时约 8–12ms
- StringBuffer 往往需要 28–45ms，慢了约 2–4 倍
这个差距不来自算法或数据结构，纯粹来自同步带来的额外字节码指令和运行时机制。锁竞争越少，相对差距越稳定；但只要加了 synchronized，就不可能比无锁版本快。
线程安全不是默认选项，而是明确需求
StringBuffer 的线程安全是有代价的，但它只在一种场景下真正必要：
- 多个线程**同时读写同一个 StringBuffer 实例**（例如作为 static 全局变量、被注入到 Spring 单例 Bean 中并跨请求复用）
- 且你无法重构为线程局部使用（如 ThreadLocal
）或不可变结果传递
如果只是方法内局部创建、拼完即弃，或者通过 ThreadLocal 隔离，用 StringBuffer 就等于主动给单线程任务加锁——白耗资源，还掩盖真实并发风险。
别忽略容量预设这个小优化
无论选哪个，如果能预估最终长度，初始化时指定容量能减少数组复制次数：
- new StringBuilder(1024) 比 new StringBuilder()（默认 16）更适合拼接长文本
- 扩容公式是 新容量 = 旧容量 × 2 + 2，频繁扩容会触发多次 System.arraycopy
这点对两者都适用，但对 StringBuilder 更值得做——它本就轻量，省下的复制开销更直接体现为性能提升。
