Java StringBuffer线程安全特性与同步机制解析

StringBuffer 的线程安全特性，本质上是通过方法级别的 synchronized 来实现的——每个修改操作都独占对象锁，以此避免多线程并发修改时数据出现错乱。

Ja va 中 StringBuffer 之所以被称为线程安全，并不是来自什么高深的设计，而是因为它所有关键的公共方法——append、insert、delete、reverse、replace——全都被声明为 synchronized。这意味着什么呢？

• 每次调用这些方法时，线程必须先获取该 StringBuffer 实例自身的锁（this）。
• 同一时刻，只有一个线程能执行该实例上的任意一个 synchronized 方法。
• 其他线程如果也想调用，会被阻塞，直到锁被释放。
• 底层依赖于 char[] 数组和 count 字段，通过同步机制，确保数组扩容、索引更新、内容写入等关键步骤不会被中断。

这就是它的线程安全边界所在——单个方法调用是安全的。但要注意的是，一旦涉及多个方法组合使用，问题就可能冒出来：

• 比如 sb.length() 和 sb.append("x")，虽然是两个独立的同步方法，但中间有可能被其他线程修改了 sb。
• 这其实就是典型的“检查后使用”（check-then-act）竞态场景：你先判断长度是否为 0，再追加内容，这两步之间并不具备原子性。
• 遇到这种情况，需要手动加锁：用 synchronized(sb) { ... } 把整个逻辑块包裹起来。

与 StringBuilder 的核心区别

两者 API 完全一致，差异集中体现在并发控制层面：

• StringBuffer：所有修改方法都加了 synchronized，适合多线程共享场景，但性能开销也很明显——实测单线程下比 StringBuilder 慢了大约 80%。
• StringBuilder：没有任何同步机制，纯粹为单线程优化设计，速度快，内存也友好。
• 如果确实需要在多线程环境中高效拼接字符串，更推荐使用 ThreadLocal 或者并行流+不可变字符串的组合，而不是全局共享一个 StringBuffer。

实际使用建议

不必为了“线程安全”这个标签而默认选择 StringBuffer：

• 绝大多数业务逻辑中，字符串拼接都发生在单一线程内（比如 Controller 层组装响应），直接用 StringBuilder 更合理。
• 只有在明确需要多个线程反复读写同一个可变字符串对象时，才应该考虑 StringBuffer。
• 注意初始容量设置（默认是 16），避免频繁扩容影响性能；有必要的话可以用 new StringBuffer(128) 预先分配。
• 调用 toString() 后，StringBuffer 内部会缓存结果（toStringCache），这在重复调用时可以提升效率。