单线程用 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 有更清晰的替代路径。
立即学习“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 参数，到底有没有逃逸到其他线程？一旦不确定，宁可重构为不可变或加显式锁，也不要赌它“应该没事”。
