单线程下stringbuilder高效关键在于避免共享、预设容量、链式调用并显式tostring。禁用stringbuffer，杜绝多线程共用，扩容开销大，需合理初始化容量，复用时用setlength(0)。
在单线程场景下，StringBuilder 要达到最高效率，关键不是“怎么用”，而是“怎么避免拖慢它”。实测表明，合理使用可比默认写法快 20% 以上——尤其在日志组装、JSON 构建、SQL 拼接等高频拼接任务中。
确保单线程独占，杜绝共享
这是前提，不是建议。只要 StringBuilder 实例被两个线程同时访问（哪怕只是读+写），就可能引发数据错乱或隐性竞争。
- Controller 方法里 new 出的 StringBuilder → 安全，每个请求独享
- Service 层局部变量拼接参数 → 安全
- static 字段持有 StringBuffer/StringBuilder → 必须改，不能直接换类名，要转为 ThreadLocal
或重构为方法内创建 - CompletableFuture 异步任务共用同一个实例 → 危险，应改为每个任务 new 一个，或用锁保护（不推荐）
预设容量，拒绝频繁扩容
默认构造 new StringBuilder() 只分配 16 字符空间。一旦超出，触发扩容（newCapacity = old × 2 + 2），伴随数组拷贝——这是吞吐量下降的主因之一。
- 拼接固定结构数据（如 500 条日志行，每行约 80 字符）→ 直接 new StringBuilder(40000)
- 动态 SQL 参数列表，预计最多 200 个字段 → 设为 new StringBuilder(2048) 或 4096，留有余量
- 不确定长度但量级明确（如 HTTP 响应体组装）→ 宁大勿小，设 8192 比反复扩容更省 CPU
- 复用 StringBuilder 时，仅调用 setLength(0) 不释放底层数组，所以预设容量只需做一次
链式调用 + 显式 toString()，不依赖隐式转换
append 等方法返回 this，支持链式调用，既简洁又避免中间变量；而 toString() 是唯一生成不可变 String 的出口，必须显式调用。
- 推荐写法：sb.append("id=").append(id).append(",name=").append(name).toString()
- 避免误区：调用 toString() 后继续 append → 逻辑上可行，但易导致语义混乱和调试困难
- 日志框架（如 Logback）若接收 StringBuilder 实例而非 String，可能复用其内部数组 → 务必传 sb.toString()
- 不要用 sb + "" 或 sb + null 触发隐式 toString()，语义不清且可能空指针
避开同步包袱，不混用 StringBuffer
StringBuffer 所有 public 方法都带 synchronized，哪怕在单线程里也会走同步入口，带来无谓开销。替换不是“语法迁移”，是彻底清除同步语义。
- IDEA 或 SonarQube 提示 “StringBuffer may be replaced with StringBuilder” → 这是性能红线，不是风格提示
- 旧代码中 StringBuffer 用于工具类计数器 → 改用 AtomicInteger 更合适，别硬套 StringBuilder
- 不要为了“看起来统一”在单线程代码里混用 StringBuffer，哪怕只有一处，也会拉低整体吞吐
- 压测对比（JDK 17，10 万次 append）：StringBuilder ≈ 12ms，StringBuffer ≈ 28ms
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
