StringBuffer 通过方法级 synchronized 锁保障线程安全，所有修改方法原子执行，配合缓存清除与显式同步可确保共享实例的内容一致性。
Java 中 StringBuffer 保障字符串内容一致性，核心靠的是方法级 synchronized 锁，确保每个公开修改操作在单个线程内原子执行，从而避免多线程并发写入导致的字符数组错乱、长度不一致或数据覆盖。
所有修改方法都被同步保护
append()、insert()、delete()、replace()、reverse() 等所有会改变内部状态的 public 方法，全部声明为 synchronized。这意味着：
- 每次调用时，线程必须先获取该 StringBuffer 实例自身的锁（
this） - 锁未释放前，其他线程无法进入任何同步方法
- 底层 char[] value 和 int count 的读写都在同一把锁下完成，保证扩容、复制、计数更新等步骤不被中断
缓存机制配合同步清除
StringBuffer 内部维护一个 toStringCache 字段缓存上一次 toString() 的结果，提升重复调用性能。但只要任意修改方法被调用，就会立即置空该缓存：
- 避免其他线程读到过期的 toString 结果
- 强制后续 toString() 重新构建字符串，确保返回内容与当前 value 数组严格一致
复合操作仍需手动加锁
单个方法安全 ≠ 多步逻辑自动安全。例如以下代码存在竞态风险：
立即学习“Java免费学习笔记（深入）”；
if (sb.length() < 10) sb.append("x");因为 length() 和 append() 是两个独立的同步方法，中间可能被其他线程修改 sb。要真正保障逻辑一致性，必须显式同步：
synchronized (sb) { if (sb.length() < 10) sb.append("x"); }- 只有整个“检查+修改”过程被同一把锁包裹，才能防止状态被外部干扰
一致性只对共享实例有效
StringBuffer 的一致性保障是有前提的：
- 多个线程必须操作同一个 StringBuffer 实例（如 static 字段、成员变量、跨 Runnable 共享）
- 如果每个线程都 new 自己的 StringBuffer，那根本不需要同步——此时用 StringBuilder 更高效
- 一致性不解决“业务语义”问题，比如拼接顺序依赖，仍需上层逻辑或额外协调
