Java StringBuilder扩容代价分析：如何预设容量大小-java教程-PHP中文网

预设 stringbuilder 容量的核心目的是避免数组扩容引发的 system.arraycopy 拷贝开销和频繁 char[] 分配导致的 gc 压力；capacity() 返回内部 char[] 总长度而非当前字符串长度，扩容公式为 newcapacity = oldcapacity × 2 + 2，预估时应加 10%~15% 余量并向上取整至 2 的幂。

java stringbuilder扩容代价分析：如何预设容量大小

预设 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+ 逻辑更平滑，但仍是非线性）。实际执行分两步：

Question AI

一款面向学习和知识查询场景的AI助手，提供问题解答、内容和智能搜索等功能。

下载

先按公式算候选值（如 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），浪费堆内存，尤其在线程局部短生命周期实例中。