预设stringbuilder容量是可预估长度场景的刚需优化，旨在减少数组复制、降低gc压力并确保真正线性耗时；典型场景包括批量日志组装、sql拼接、json构建和模板渲染，预估需加10%~15%余量并向上取整至2的幂。
预设 StringBuilder 容量不是“锦上添花”，而是对可预估长度场景的刚需优化——它直接减少数组复制次数，降低 GC 压力，让拼接耗时从线性退化回归到真正线性。
什么时候必须预设容量？
当拼接内容总量相对固定、可粗略估算时，就该预设。典型场景包括：
- 批量日志行组装（如每条日志约 120 字符 × 5000 条 → 预估 60 万字符）
- SQL INSERT 语句拼接（字段名 + 值 + 逗号分隔符，结构稳定）
- JSON 数组构建（对象模板已知，变量长度有上限）
- 模板渲染（HTML 片段 + 若干动态字段，最大长度可推）
怎么算才靠谱？留余量，别抠数字
预估目标不是“刚刚好”，而是让最终 length() 落在 capacity() 的 80%～90% 区间。实操建议：
- 固定集合拼接：累加所有字符串 length()，再加 10%～15% 波动余量（比如 ID 可能为空或超长）
- 模板+变量：模板字面长度 + 各变量最大可能长度 + 分隔符/换行等额外开销（例如 "id={}&name={}" + id.length() + name.length() + 10）
- 向上取整到 2 的幂：1800 → 2048，3500 → 4096（内存对齐友好，JVM 分配更高效）
常见预设错误与规避方式
预设不当反而浪费内存或失去效果：
- 设太小：如拼接 10000 字符却只设 1024，仍会多次扩容（16→34→70→142→286…），拷贝开销不减反增
- 设太大：预估 10MB 实际只用 10KB，堆内存浪费明显，尤其在线程局部短生命周期实例中
- 在循环里调 ensureCapacity()：每次判断都带方法调用开销，且几乎无效；应提前在循环外一次性预留
如何验证预设是否生效？
光看代码不够，得运行时确认：
- 用 sb.capacity() 和 sb.length() 对比：循环结束后若 length() / capacity() ，说明余量过大；若接近 1.0 但仍有扩容，说明预估偏低
- 开启 JVM 参数 -XX:+PrintGCDetails，观察 young GC 次数是否显著下降
- 用 JFR 录制，筛选 jdk.ArrayCopy 事件，看是否高频出现在 StringBuilder.ensureCapacityInternal 中
- 做压测对比：同一逻辑，new StringBuilder(4096) vs new StringBuilder()，看耗时与 GC 时间差值
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
