预估 stringbuilder 初始容量应精确计算所有内容长度加结构开销，直接使用带参构造器（如 new stringbuilder(4096)），避免扩容；复用时用 setlength(0) 清空，压测验证 capacity 始终 ≥ length 且 ensurecapacity 调用为 0。
预估 StringBuilder 初始容量，核心是让底层数组一次分配到位，全程不触发扩容——这比依赖默认 16 容量或循环中反复调 ensureCapacity 更直接、更轻量。
拼接前统计算法能覆盖的最大字符数
不要靠猜，要算：把所有待拼内容的长度加起来，再补上分隔符、换行、引号、括号等结构开销。例如：
- 拼接 200 个平均 15 字符的字符串，用逗号分隔 → 200 × 15 + 199 = 3199，取 3400 或向上对齐到 4096（2¹²）
- 生成 JSON 数组，1000 个对象，每个键值对约 20 字符 → 1000 × 20 = 20000，预留 22000 即可
- 解析 CSV 行前，先按字段最大可能长度 + 分隔符 + 换行符估算整行上限，再调
sb.ensureCapacity(lineEstimate)
优先用带参构造器，而不是事后补救
如果预估明确，直接用 new StringBuilder(estimatedTotalLength)。它在实例创建时就完成数组分配，语义清晰，无冗余方法调用：
-
new StringBuilder(4096)比new StringBuilder().ensureCapacity(4096)少一次方法开销 - 设为 4096 后，哪怕最终只用到 3900，也彻底避开扩容路径（16→34→70→142…）
- 避免设得过大：拼 300 字符却设 10000，会浪费堆内存，增加 GC 压力
复用实例时保留 capacity，别每次都 new
高频场景（如日志收集、模板渲染）下，用 setLength(0) 清空逻辑长度，不释放底层数组：
- 下次
append()直接覆盖，零拷贝、不触发 GC - 比每次
new StringBuilder()快得多，尤其在循环内反复使用时 - 若后续拼接明显变长，可在
setLength(0)后再调一次ensureCapacity预留新空间
验证是否真没扩容
写了预估不等于起效，得看实际行为：
- 压测时检查
sb.capacity()是否始终 ≥sb.length()，且全程不变 - 用 JFR 或 VisualVM 查
StringBuilder.ensureCapacity调用次数是否为 0 - 对比 GC 日志：若
char[]分配频次显著下降，说明扩容开销确实被绕过了
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
