stringbuilder性能优于stringbuffer主要因省略同步开销，实测快2–6倍；二者扩容机制完全相同；优化重点应是预设容量、复用实例和避免不必要的可变字符串。
在非线程安全场景下，StringBuilder 的性能优势主要来自免除了同步开销，实际提升通常在 10%–35%，具体取决于操作频率、字符串长度和 JVM 版本。
同步机制是性能差异的根源
StringBuffer 所有公开方法（如 append()、insert()、delete()）都用 synchronized 修饰，每次调用需获取对象锁。即使单线程执行，JVM 仍要走完整的锁进入/退出流程，包括内存屏障、指令重排序限制等底层开销。
StringBuilder 完全省略这些控制，方法体逻辑与 StringBuffer 几乎一致，仅少一层同步包裹——这意味着它更接近直接操作底层 char[] 或 byte[] 数组的效率。
实测数据可量化差距
以 10 万次简单拼接（如追加短字符串 "a"）为例，在主流 JDK 17+ 环境下典型结果如下：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- StringBuilder：约 6–9 毫秒
- StringBuffer：约 22–38 毫秒
- String 直接拼接（
+=）：约 1200+ 毫秒（作为对比基准）
差距并非固定比例，当操作链变长（如连续 append().insert().reverse()），或单次追加内容较大时，StringBuilder 的优势会进一步放大，因为同步锁的累积代价随调用次数线性增长。
扩容行为完全一致，不构成差异点
两者均继承自 AbstractStringBuilder，共享同一套扩容逻辑：
- 初始容量默认为 16
- 扩容公式为 newCapacity = oldLength × 2 + 2
- 若仍不足，则直接扩到所需最小容量
也就是说，性能差异与内存分配、数组复制等环节无关，纯粹由同步机制引入的运行时成本导致。
真实项目中更值得关注的优化点
单纯替换 StringBuffer 为 StringBuilder 带来的提速虽明确，但往往不如以下做法影响大：
- 预先估算最终长度，用带初始容量的构造函数（如
new StringBuilder(1024)），避免多次扩容 - 避免在循环内反复创建新实例；复用局部变量比纠结同步更有效
- 确认是否真需要可变字符串——若拼接逻辑固定，用静态字符串常量或编译期优化（如字符串连接优化）更优
只要确保单线程使用，StringBuilder 就是默认合理选择，无需额外权衡。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
