单线程场景必须用stringbuilder替代stringbuffer，因其无同步开销、吞吐量高10%–15%；多线程应使用threadlocal或传参方式规避共享，禁用static声明。
在高性能开发中，StringBuilder 替代 StringBuffer 的核心不是“能不能换”，而是“必须换”——只要场景是单线程，StringBuffer 就是性能冗余。
为什么 StringBuilder 天然比 StringBuffer 快
StringBuffer 每个 public 方法（如 append()、toString()）都加了 synchronized 关键字，强制串行执行；而 StringBuilder 完全去掉了这层锁开销。实测表明，在纯拼接场景下，StringBuilder 吞吐量比 StringBuffer 高 10%–15%，且随着 CPU 核心数增加，差距更明显——因为锁竞争会随并发线程增长而恶化。
- StringBuffer 的同步粒度是整个对象，哪怕两个线程 append 不同内容，也得排队
- 绝大多数业务代码（Controller、Service、DAO、日志组装、SQL 构建）都在单线程上下文中执行，根本不需要跨线程共享同一个 StringBuilder 实例
- IDEA、SonarQube 等工具将 “StringBuffer 可替换为 StringBuilder” 标为性能红线，而非普通建议
多线程场景下不硬扛 StringBuffer
真有跨线程拼接需求时，靠 StringBuffer 并不能真正解决问题：它只保证单个方法原子性，无法保证逻辑上的事务一致性（比如先 append A 再 append B，中间被其他线程插入 C，结果就错乱）。正确做法是规避共享，而非加锁。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 用 ThreadLocal
为每个线程提供专属实例，零锁、零竞争 - 把 StringBuilder 当作方法参数传入，由调用方负责创建和回收，作用域清晰可控
- 绝对避免将其声明为 static 字段或全局 Bean——这是典型的线程安全幻觉
替代后必须同步升级的使用习惯
换掉 StringBuffer 只是第一步，配套写法不改，照样掉坑里：
- 构造时务必指定初始容量：new StringBuilder(4096)，而不是默认的 16；否则频繁扩容（old × 2 + 2）引发数组拷贝，比多分配内存更伤性能
- 日志输出时显式调用 sb.toString()，例如 log.debug("result={}", sb.toString())；直接传 sb 可能被 Logback 等框架复用内部 char[]，导致日志内容污染
- toString() 后 StringBuilder 仍可继续 append()，不必 new 新实例——已累积的内容不该丢弃
一句话结论
StringBuffer 是为“假想的通用线程安全需求”设计的过渡方案；现代 Java 高性能开发中，单线程用 StringBuilder，多线程用 ThreadLocal + StringBuilder，既干净又极致——这才是真实工程中的标准解法。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
