stringbuffer 通过方法级 synchronized 锁保障多线程操作完整性，所有修改方法（如 append、insert）均同步于 this 实例，确保 char[] value 和 count 的一致更新，结果内容完整、无越界或错乱，但不保证执行顺序；需避免非原子复合操作，并配合合理初始化与使用方式。
StringBuffer 在多线程逻辑中保障操作完整性，靠的是方法级 synchronized 锁，不是靠避免共享，而是让共享变得可控——所有修改内部状态的操作（如 append、insert、delete）都被强制串行执行。
同步机制直接作用于对象实例
每个 public 修改方法都声明为 public synchronized，锁目标是当前 StringBuffer 实例（this）。这意味着：
- 线程 A 调用
sb.append("A")时，会持有该实例锁； - 此时线程 B 若调用
sb.append("B")，必须等待 A 完成并释放锁； - 底层共享的
char[] value和int count始终由同一把锁保护，不会出现写一半被中断、计数错乱或数组越界。
完整性体现在结果可预期，而非顺序可预测
多个线程共用一个 StringBuffer 实例时：
- 每个
append操作的内容完整保留，不会截断、不会混入乱码； - 不会抛
ArrayIndexOutOfBoundsException或导致count > value.length； - 最终字符串一定是各次 append 内容的某种排列组合，比如 "A" 和 "B" 的结果只能是 "AB" 或 "BA"，绝不会是 "A\0B" 或部分字符丢失。
需避开非原子复合操作
方法级同步只保单个方法的原子性，不保多步逻辑。以下写法仍可能出错：
- 先调用
sb.length()判断长度，再根据结果决定是否append——中间可能被其他线程插入内容； - 在
synchronized(sb)块外读取sb.toString()后又继续append，破坏了操作连贯性； - 用反射直接修改
value数组或count字段，绕过同步逻辑，完整性立即失效。
初始化与使用方式影响实际稳定性
光有 synchronized 不够，还需配合合理实践：
- 创建时预估容量：
new StringBuffer(1024)，减少扩容时的锁竞争和数组复制； - 避免高频短生命周期共享：如每毫秒上百次 append 的场景，锁争抢会急剧放大延迟；
- 不暴露为静态全局变量供大量线程无节制访问，应封装在有明确作用域的工具类中；
- 若只需最终合并结果，优先让各线程用独立 StringBuilder，最后用 StringBuffer 或
String.join()汇总。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
