关键在于合理设置stringbuilder容量：预估最大字符数并加5%～10%余量，向上取整至2的幂（如3800→4096），优先用带参构造器；设大浪费内存，设小仍扩容；需通过gc频率、arraycopy事件和压测验证效果。
关键不是“用不用”capacity 和 ensureCapacity，而是“设多少、什么时候设、怎么确认它真起效了”。默认容量 16 在多数业务场景里根本不够用，一拼就扩容，每次扩容都要复制整个底层数组，拖慢速度还推高 GC 压力。
预估总长再一次性设置容量
别在循环里边拼边判断——那只会白费方法调用，append 内部本就做了扩容判断。正确做法是：拼接前统计算法能覆盖的最大字符数，加 5%～10% 余量（应付分隔符、换行、字段长度波动），然后调一次 ensureCapacity 或直接用带参构造器。
- 集合拼接：用
list.stream().mapToInt(String::length).sum()算原始长度，再加逗号数、括号、空格等固定开销 - 模板渲染：把模板字面量长度 + 各变量最大可能长度 + 符号（如
&、{}）全加起来 - 有上限但不确定：比如日志缓冲上限 2MB，直接
ensureCapacity(2 * 1024 * 1024)
容量值建议向上取整到 2 的幂
JVM 对 2 的幂大小的数组分配更友好，内存对齐效率高。预估 3800 字符，别设 3800 或 4000，选 4096；预估 7200，选 8192 更稳妥。这不是经验之谈，而是 JVM 底层内存分配机制决定的。
- 可用工具逻辑封装：例如
Integer.highestOneBit(n * 12 / 10) - 默认扩容路径是 16 → 34 → 70 → 142 → 286… 跳变剧烈且不规整；设为 4096 后，哪怕最终只用到 3900，也完全避开任何扩容
构造函数比 ensureCapacity 更简洁
如果预估非常明确，直接用带参构造器更干净：new StringBuilder(estimatedTotalLength)。它在初始化时就完成内存分配，省去后续方法调用，语义也更清晰。
- 适合场景：SQL 拼接（字段名+值结构固定）、JSON 数组构建（对象模板已知）、批量 CSV 导出（每行列宽可控）
- 注意：构造参数是 capacity，不是 length；设大了浪费堆内存，设小了照样触发扩容
- 若预估偏差较大（比如某些字段可能为空或超长），仍推荐先 new 默认实例，再用 ensureCapacity 动态补足
运行时验证是否真正生效
写了 ensureCapacity 不代表效果自动落地，得看指标：
- 启用
-XX:+PrintGCDetails，观察 Young GC 频率是否下降——频繁短数组分配和拷贝常伴随 GC 突增 - 用 JFR 抓
jdk.ArrayCopy事件，如果调用栈里高频出现StringBuilder.ensureCapacityInternal，说明扩容太勤 - 做简单压测：同一逻辑，对比
new StringBuilder()和new StringBuilder(4096)的耗时与 GC 次数，差距往往立竿见影
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
