StringBuffer仅适用于多线程长期共享同一实例并持续并发修改的场景，如全局日志聚合器；其方法级同步不保证业务逻辑安全，高并发下性能差，应优先用ThreadLocal<StringBuilder>或SLF4J。
在高并发Web环境中，StringBuffer不是首选方案，但确有其不可替代的适用边界——关键不在于“能不能用”，而在于“该不该共享、值不值得锁”。它提供的线程安全是方法级原子性，不是业务逻辑级安全，用错场景反而会拖垮吞吐量。
明确适用前提：真需要共享+并发修改
只有当多个线程**长期共用同一个StringBuffer实例**，并**持续对其做追加、插入等修改操作**时，才考虑StringBuffer。典型例子：
- 全局日志聚合器（如自研轻量级日志缓冲池，多线程写入后统一刷盘）
- HTTP响应头动态拼接器（多个过滤器/拦截器协同向同一buffer写入Header字段）
- 遗留系统中被多个Service Bean注入并复用的字符串组装工具类
反例：在Spring MVC Controller方法内new一个StringBuffer再传给几个子线程——此时每个线程应各自持有StringBuilder，或用ThreadLocal包装。
避开常见陷阱：同步≠事务，方法原子≠操作安全
StringBuffer的synchronized只保单个方法执行不交错，不保多步逻辑一致性。以下代码危险：
立即学习“Java免费学习笔记（深入）”；
if (buf.length() < 10) {
buf.append("default");
}
因为length()和append()之间可能被其他线程插入修改。正确写法是手动加锁：
synchronized (buf) {
if (buf.length() < 10) {
buf.append("default");
}
}
另外注意：toString()返回新String对象，后续对该String的操作不再受StringBuffer锁保护；且JDK 9+中toStringCache在并发调用下频繁失效，反而降低性能。
性能红线：别把它当高性能方案
StringBuffer的synchronized锁是粗粒度的——整个对象实例被锁住。在QPS过万的Web服务中，多个请求线程争抢同一buffer锁会导致严重排队。实测表明，线程数从4增至16时，吞吐量可能下降60%以上。
替代建议：
- 优先用ThreadLocal<StringBuilder>：每个线程独享实例，零锁开销，初始化成本极低
- 对日志类场景，直接用SLF4J参数化日志（
log.info("Order {}, status {}", id, status)），避免手动拼接 - 若必须聚合多线程结果，改用ConcurrentLinkedQueue收集片段，最后由单线程合并
初始化与重用：减少扩容与GC压力
StringBuffer默认容量16，超出即按当前容量翻倍扩容（如16→32→64），触发char[]数组拷贝。高频拼接场景务必预估长度：
- 构造时指定合理初始容量：
new StringBuffer(512)（例如日志行平均长度300字符） - 重用实例时调用
setLength(0)清空内容，复用底层char[]，避免反复分配内存 - 避免在循环体内反复new StringBuffer——这比用+拼接还糟
注意：setLength(0)仅重置count指针，value数组仍保留，toString()只取有效长度部分，安全可靠。
