StringBuffer线程安全靠方法级synchronized锁住this对象，确保单个操作原子性；但多步操作需显式同步，且仅当多线程共享并并发修改同一实例时才必要。
Java 中 StringBuffer 在多线程环境下保持状态同步，靠的是每个修改方法（如 append、insert、delete、reverse）都声明为 synchronized，锁住当前实例对象（this），确保同一时刻只有一个线程能执行这些操作。但这只保障单个方法内部的原子性，不自动保护跨方法的逻辑。
同步机制怎么起作用
StringBuffer 的同步是方法级的，不是全局或类级的：
- 每次调用
append()或delete()等方法时，线程必须先获取该 StringBuffer 实例的对象锁 - 若锁已被占用，后续线程会阻塞等待，直到前一个线程释放锁（方法执行完或异常退出后自动释放）
- 不同 StringBuffer 实例之间互不影响——
sb1和sb2可被多个线程同时操作，不会争抢同一把锁 - 非同步方法如
length()、charAt()可并发读取，不参与锁竞争
单方法安全 ≠ 多步操作安全
两个 synchronized 方法之间没有原子性，容易出现“检查后使用”竞态：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 错误示例：
if (sb.length() —— <code>length()返回 9 后，另一线程可能立刻清空sb，再执行append就违背原意 - 正确做法：用显式同步块包裹整个判断+操作逻辑：
synchronized (sb) { if (sb.length() - 所有涉及“读-判-改”的复合逻辑，都需手动加锁，不能依赖方法自身的 synchronized
什么时候真需要 StringBuffer
它只在明确满足以下条件时才必要：
立即学习“Java免费学习笔记（深入）”；
- 多个线程共享同一个 StringBuffer 实例（比如作为
static字段、或被多个 Runnable 共同引用） - 这些线程会并发地读写该实例（不只是各自创建、拼接、丢弃）
- 典型场景：日志聚合器中多线程向同一缓冲区追加日志；旧版 Servlet 共享响应构建器（现已少见）
- 反例：循环内每次
new StringBuffer()，或仅本线程临时拼接——此时用 StringBuilder 更快，性能高 2–3 倍
性能代价与更优替代方案
同步带来可测开销，尤其在高竞争场景下：
- 单线程下，StringBuffer 比 StringBuilder 慢约 15%–20%；10 线程争抢同一实例时，吞吐量可能下降 60% 以上
- 推荐替代方式：
ThreadLocal<StringBuilder>（每个线程独享，零锁）、ConcurrentLinkedQueue收集片段后合并、或直接避免共享（让拼接限定在单线程上下文） - 注意初始容量设置（默认 16），频繁扩容会影响性能；必要时用
new StringBuffer(128)预分配
