预设 StringBuilder 容量的核心目的是避免数组扩容引发的 System.arraycopy 拷贝开销和频繁 char[] 分配导致的 GC 压力；capacity() 返回内部 char[] 总长度而非当前字符串长度，扩容公式为 newCapacity = oldCapacity × 2 + 2，预估时应加 10%~15% 余量并向上取整至 2 的幂。
预设 StringBuilder 容量的核心目的，是避免因数组扩容引发的 System.arraycopy 拷贝开销 和 频繁临时 char[] 分配带来的 GC 压力。它不难，但容易被忽略——尤其在批量日志拼接、SQL 组装、模板渲染等可预估长度的场景中。
容量 ≠ 长度：先搞清 capacity() 返回什么
capacity() 返回的是内部 char[] value 数组的长度，即已分配的总空间；而 length() 才是当前已写入的字符数。例如：
-
new StringBuilder("abc")→length() == 3，capacity() == 19（字符串长3 + 默认预留16） -
new StringBuilder()→capacity() == 16，length() == 0
只要 length() + 新增字符数 > capacity()，下一次 append() 就会触发扩容——此时真正耗时的是拷贝已有 count 个字符，不是扩容计算本身。
扩容怎么算？不是“加16”，而是成倍增长
扩容公式为：newCapacity = oldCapacity × 2 + 2（JDK 11+ 逻辑更平滑，但仍是非线性）。实际执行分两步：
立即学习“Java免费学习笔记（深入）”；
- 先按公式算候选值（如 16 → 34 → 70 → 142…）
- 若该值仍小于所需最小容量（即
currentLength + appendLen），则直接取最小容量（如需存 100 字符，16×2+2=34 不够，就一步扩到 100）
这意味着：从 16 开始拼接 200 字符，大概率经历 4 次扩容（16→34→70→142→200），每次都要拷贝全部已有内容；而直接 new StringBuilder(200)，全程零拷贝。
怎么预估才合理？留余量，别死抠
预估目标不是“绝对精确”，而是让最终 length() 落在 capacity() 的 80%~90% 区间内。常用方法：
- 固定集合拼接：遍历所有待拼字符串，累加
String.length()，再加 10%~15% 波动余量（如日志字段可能含空值或超长 ID） - 模板+变量：按模板字面长度 + 各变量最大可能长度（如
"id={}&name={}"+id.length()+name.length()+ 10） - 向上取整到 2 的幂：1000 → 1024，3000 → 4096（内存对齐友好，部分 JVM 优化更充分）
避免两种极端：设太小（仍频繁扩容），或设太大（如预估 10MB 实际只用 10KB），浪费堆内存，尤其在线程局部短生命周期实例中。
什么时候该用 ensureCapacity()？
适合动态估算场景，比如循环读取流式数据、拼接不定条数的日志行：
- 在关键节点调用一次（如循环前、处理第 100 条后），传入预估的总长，而非在
for循环体内反复调用 - 它只扩容、不缩容；多次调用无副作用，但无谓调用会增加方法开销
- 若完全无法预估（如解析未知长度的 HTTP 响应体），硬设 capacity 反而误导，可考虑分块处理或改用
StringBuffer（同步开销换稳定性）
