防止 stringbuilder 性能退化需避开四大反模式：容量失控（预估并指定初始容量，避免默认16导致频繁扩容复制）、实例滥用（循环外创建、复用，用 setlength(0) 清空）、调用错位（循环后统一 tostring，禁循环内调用）、类型误用（链式 append 优于字符串拼接表达式，数字优先用原生 append 方法）。
防止 StringBuilder 在循环拼接中性能退化，核心不是“用了没”，而是避开几个高频反模式：容量失控、实例滥用、调用错位和类型误用。真正拖慢的从来不是 append 方法本身，而是背后隐含的对象分配与数组复制。
预估容量，避免反复扩容
默认初始容量 16，一旦超出就会扩容（新容量 ≈ 旧容量 × 2 + 2），每次扩容都要复制整个底层数组——这是隐藏开销主力。
- 能估算就直接指定：比如拼接 500 个平均长度 40 的字符串加逗号分隔，总长 ≈ 500×40 + 499 ≈ 20500，写 new StringBuilder(20500)
- 不确定但数据量大，宁可高估 10%–20%，也别依赖默认值；完全无法预估时，至少设为 new StringBuilder(4096)
- 别指望 ensureCapacity() 补救——它只扩不缩，还多一次方法调用
复用实例，禁止循环内新建
在循环体里每次 new StringBuilder()，等于把优化全抵消了：对象创建、初始化、GC 压力一样不少。
- 正确做法：在循环外创建一次，循环内只调 append()
- 多次独立拼接（如批量生成日志或 SQL）：用 sb.setLength(0) 清空内容，保留底层数组，比 new 快得多
- 多线程场景：绝不能共享同一个实例；改用 ThreadLocal 每线程一个，或每个线程独立创建
只 append，不提前 toString
toString() 是复制整个 char 数组生成新 String 的操作，时间复杂度 O(n)。在循环里每轮都调，等于白用 StringBuilder。
- ✅ 正确：循环结束后统一调一次 sb.toString()
- ❌ 错误：循环内写 result = sb.append(s).toString()，每次都在造新 String
- 拼接过程中需要中间结果？优先考虑逻辑拆分，而不是靠 toString 截断
链式 append，避开隐式字符串构造
看似等价的写法，底层行为天差地别。关键在于是否引入额外的临时对象。
- ✅ 推荐：sb.append("id:").append(id).append(", name:").append(name) —— 链式调用，无临时字符串
- ❌ 避免：sb.append("id:" + id + ", name:" + name) —— 编译器先用另一个 StringBuilder 拼出临时串，再 append，多一次构造+toString
- 数字拼接优先用 append(int)、append(long)，比 append(String.valueOf(n)) 少一次对象创建
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
