Java 中 StringBuffer 如何处理多线程环境下的字符串拼接

StringBuffer 的线程安全机制，说白了，就是在所有修改方法上加了 synchronized 锁——像 append、insert、delete 这些操作，都被同一把 this 锁保护着。同一时刻只允许一个线程进来修改内部的 char[] 数组和 count 字段，数据一致性算是保住了。代价你也猜到了：性能比无锁的 StringBuilder 差一截。

一句话概括：StringBuffer 是线程安全的，适合多线程环境下的字符串拼接。 它通过在所有修改方法上加 synchronized 来保证并发安全，但性能开销比非同步的 StringBuilder 更大。

为什么 StringBuffer 能在多线程中安全使用

关键设计其实不复杂：每个可能改变内部状态的方法都被声明为 synchronized，说白了就是同一时刻只放一个线程进来操作。比如：

• append(String) 整体被锁住，多个线程调用时乖乖排队；
• 内部字符数组 char[] value 的读写不会出现脏读、丢失更新这种糟心事；
• 扩容逻辑（比如 ensureCapacity）也受同步保护，避免多个线程同时触发数组复制导致数据错乱。

典型多线程使用方式

最常见的就是把 StringBuffer 实例作为共享对象，多个线程直接调用 append()，不用额外加锁。实践中常见于日志聚合、配置拼接、批量构建文本这类场景。不过得注意：操作是线程安全的，但最终拼接结果的业务语义还得自己把握——比如拼接顺序是否重要，这个锁可管不了。

与 StringBuilder 的对比选择

选择其实挺明确的：

• 明确只在单线程中使用 → 优先选 StringBuilder，功能一样但没同步开销，性能更好；
• 多线程且需要共享拼接结果 → 用 StringBuffer；
• 多线程但每个线程各自拼接、不共享实例 → 单个线程内用 StringBuilder 更高效；
• 对性能敏感且需要更高并发能力，可以考虑用 ThreadLocal 来避免锁竞争。

实际编码注意事项

虽然线程安全，但有些细节会影响正确性和效率：

• 不要在同步块外缓存或暴露内部数组（比如调了 toString().toCharArray() 后还要修改它）；
• 避免在循环中频繁创建新 StringBuffer 实例，复用更明智；
• 如果只是拼接固定数量字符串，用 String.join() 或 String.concat() 可能更简洁；
• 高并发下大量拼接，可以评估是否改用 ConcurrentLinkedQueue + 合并策略，而非死磕一个同步对象。