单线程场景应优先使用 StringBuilder 而非 StringBuffer，因其无同步开销、性能高 10%–15%，且 JVM 更易优化；StringBuffer 的 synchronized 机制在单线程下纯属冗余，不提升安全性却浪费资源。
因为 StringBuffer 的同步机制在单线程下纯属冗余开销。
StringBuffer 的每个关键方法（如 append()、insert()、delete()）都用 synchronized 修饰，确保多线程并发修改时数据一致。但同步意味着每次调用都要获取锁、检查锁状态、释放锁——这些操作在单线程里完全没必要，反而拖慢执行速度。
实际性能差距明显：基准测试显示，相同字符串拼接逻辑下，StringBuilder 通常比 StringBuffer 快 10%–15%。如果拼接量大（比如循环构建 SQL 或 JSON），这个差距会更显著。
- 同步不带来任何安全收益：单线程不存在竞态条件，加锁既不防 bug，也不提升正确性
- 内存与 CPU 都被浪费：锁的维护、上下文切换（哪怕极轻量）占用资源
- JVM 无法优化：
synchronized方法限制了 JIT 编译器的部分内联和消除机会
所以不是 StringBuffer “不好”，而是它被设计用来解决一个你当前并不面临的问题——多线程共享修改。把它用在单线程场景，就像给自行车装坦克履带：能动，但笨重、低效、不合逻辑。
立即学习“Java免费学习笔记（深入）”；
简单说：用错场合，不是类本身有问题。
如果你确认整个字符串操作生命周期只在一个线程内（比如方法局部变量、Stream 中的 map 操作、Controller 层单次请求处理），那就直接选 StringBuilder。需要线程安全？再考虑 StringBuffer，或更现代的替代方案（如 ThreadLocal<StringBuilder>）。
