17370845950

单线程用 StringBuilder，多线程用 StringBuffer——必须根据线程环境选择：前者无锁高效，后者同步安全；误用会导致数据错乱或性能浪费。

StringBuffer 和 StringBuilder 该用哪个？看线程环境就对了

单线程用 StringBuilder，多线程用 StringBuffer——这是最直接、最安全的选择逻辑。不是“推荐”，而是“必须”：选错会导致隐性 bug 或性能浪费。

• 如果你的字符串操作只发生在主线程、一个 Runnable、或某个工具方法内部（比如解析 JSON 字段拼接日志），StringBuilder 是默认且唯一合理的选择
• 如果你在多个线程里共用同一个字符串容器（例如多个线程往同一个 StringBuffer 对象调用 append()），不用 StringBuffer 就会出数据错乱——比如漏字符、重复插入、甚至 ArrayIndexOutOfBoundsException
• 别幻想“我代码看起来是单线程，但框架可能偷偷开线程”。Spring 的 @Async、Servlet 容器线程池、CompletableFuture 回调，都可能把你拖进多线程场景

为什么 StringBuffer 线程安全却更慢？看 synchronized 的实际开销

StringBuffer 的每个公共方法（append()、insert()、delete() 等）都加了 synchronized 锁；StringBuilder 完全没这层机制。这不是“设计差异”，而是明确的取舍：用锁换安全，用无锁换吞吐。

• 在单线程下，synchronized 仍需进入监视器、检查锁状态、可能触发偏向锁撤销——实测中，高频拼接（如循环 10 万次 append）时，StringBuilder 比 StringBuffer 快 10%–15%
• 锁粒度是整个对象，不是某段字符。哪怕两个线程往不同 StringBuffer 实例写，互不影响，但只要它们方法被同步，JVM 就无法优化掉锁开销
• 没有“部分同步”或“读写分离”的中间方案——Java 标准库没提供线程安全又轻量的字符串构建器

常见误用场景：你以为安全，其实不安全

很多人以为“用了 StringBuffer 就高枕无忧”，但线程安全只保证容器自身操作原子，不保证业务逻辑整体安全。

• 错误写法：多个线程共享一个 StringBuffer，但先 length() 再 append() ——这俩操作之间可能被其他线程插入，导致越界或覆盖
• 错误假设：把 StringBuffer 当作线程安全的“全局日志缓冲区”，却没加外部同步控制输出时机，结果日志行混在一起（如 "user1 logged inuser2 logged in"）
• 典型陷阱：在 for 循环里创建局部 StringBuffer，却把它传给另一个线程执行（比如 executor.submit(() -> sb.append("done"))）——这时变量逃逸，局部对象变成共享对象，必须用 StringBuffer，但更要警惕生命周期管理

替代方案比死守 StringBuffer/ StringBuilder 更值得考虑

真遇到复杂并发字符串操作，硬套 StringBuffer 往往是妥协而非解法。现代 Java 有更清晰的替代路径。

• 优先用不可变 + 函数式：用 Stream + Collectors.joining() 替代手动拼接，天然线程安全且语义清晰
  

  String result = list.stream().map(Object::toString).collect(Collectors.joining(", "));

• 需要累积状态？用线程本地存储：ThreadLocal 可避免锁竞争，又不牺牲性能
  

  private static final ThreadLocal TL_SB = ThreadLocal.withInitial(StringBuilder::new);

• 异步日志、消息拼装等场景，直接用现成库（如 Log4j 的 ParameterizedMessage、Jackson 的 JsonGenerator）——它们内部已做最优缓冲策略，无需你手搓

真正难的不是记住“StringBuffer 同步、StringBuilder 不同步”，而是在堆栈深处判断：那个被传了三次的 StringBuilder 参数，到底有没有逃逸到其他线程？一旦不确定，宁可重构为不可变或加显式锁，也不要赌它“应该没事”。