直接预估并设置合理初始容量是提升StringBuilder效率最有效做法，需按模板拼接、批量处理、循环拼接等场景估算并留余量，辅以ensureCapacity动态补救、setLength(0)复用及避开初始化过大、循环新建等陷阱。
直接预估并设置合理初始容量，是提升 StringBuilder 效率最有效、最易落地的做法。它不改变业务逻辑，却能显著减少数组复制和 GC 压力。
怎么估算初始容量才靠谱
关键不是追求绝对精确，而是留出弹性余量，避免频繁扩容：
- 静态模板拼接（如 JSON 模板 + 几个变量）：把模板字符数 + 所有变量最大可能长度加总，再乘以 1.1～1.15
- 集合批量处理（如 List<String> 转 CSV）：遍历一次 sum += str.length()，然后 +64 或向上取整到最近的 2 的幂（例如 1980 → 2048，3800 → 4096）
- 循环拼接 N 条记录：每条平均长度 L，设为 N × L + 64（+64 是分隔符、换行等常见开销）
- 完全不可知但数据量大：宁可略高估（比如 +20%），也别依赖默认 16
什么时候该用 ensureCapacity
它适合在运行时动态补救，而不是代替初始化预估：
- 解析完头部信息后，已知后续内容大致范围，调一次 sb.ensureCapacity(expectedMax)
- 在方法入口或循环开始前调用，避免在循环体内反复判断
- 多次调用无副作用，但别写成
sb.ensureCapacity(sb.length() + len)——徒增方法调用开销且基本无效
复用比新建更省资源
高频场景下，反复 new StringBuilder 反而拖慢性能：
立即学习“Java免费学习笔记（深入）”；
- 单任务内多个拼接阶段（如先拼 header，再拼 body，最后加 footer），用 setLength(0) 清空比 new 快得多
- 方法内局部复用即可，无需 ThreadLocal；除非跨线程，否则不用 StringBuffer
- setLength(0) 不复制数组、不检查边界，只是重置长度指针，开销极低
避开常见陷阱
一些看似合理、实则伤性能的操作：
- 设初始容量为 10000 却只拼 200 字符：浪费堆内存，小 char[] 频繁分配反而加重 GC
- 在 for 循环里每次 new StringBuilder()：对象创建 + 初始化 16 字节数组，叠加 GC 压力
- append(null)：JDK 8+ 直接抛 NullPointerException，需提前判空或用 Objects.toString(str, "")
- 用 delete(0, length()) 替代 setLength(0)：前者要移动内容、做边界检查，更慢
