该指定capacity。默认16容量易致频繁扩容，引发Arrays.copyOf开销和GC增加；应按总长预估并加余量，避免过大浪费内存；StringBuffer扩容行为相同但性能更低；固定拼接优先用+、String.join等优化方案。
StringBuilder初始化时该不该指定capacity
该。不指定就容易触发多次数组扩容，尤其拼接内容长度可预估时。默认构造函数用的是 16 初始容量，只要最终字符串长度超过这个数，StringBuilder 就得扩容——底层是数组复制，开销不小。
常见错误现象：StringIndexOutOfBoundsException 倒不会出，但压测时发现 CPU 花在 Arrays.copyOf 上占比突增，GC 次数也变多，基本就是扩容太勤。
- 估算总长：把所有待拼字符串长度加起来，再加个余量（比如 +10% 或 +32）
- 别死算：如果拼的是日志模板+几个变量，直接按模板长度 + 各变量最大可能长度估算
- 过犹不及：设成
10000却只拼 200 字符，浪费堆内存，对小对象 GC 反而不利
capacity设小了会怎样？扩容机制怎么走
扩容不是线性增长，而是“当前容量 × 2 + 2”。比如从 16 扩到 34，再到 70，然后 142……每次扩容都要 new 新数组、copy 旧内容。
使用场景：循环内反复 append 不定长字符串（比如解析 CSV 行），若初始 capacity 远小于实际需要，一次循环可能触发 3–5 次扩容。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 扩容发生在
ensureCapacityInternal内部调用，你写代码时看不到，但 jstack 或 JFR 能抓到Arrays.copyOf的热点 - 扩容阈值判断依据是
count + len > value.length，其中count是当前字符数，len是本次要 append 的长度 - 注意：
setLength(0)不释放底层数组，只是清空逻辑长度；下次append仍可能触发扩容（如果新内容超出现有数组长度）
StringBuffer和StringBuilder的capacity行为一样吗
一样。扩容逻辑、初始容量、ensureCapacity 方法实现完全一致。区别只在同步——StringBuffer 每个 public 方法都加了 synchronized，而 StringBuilder 没有。
性能影响明显：单线程下 StringBuilder 通常快 2–3 倍；多线程共享同一个实例时，用 StringBuffer 也不解决根本问题——锁竞争反而更重，不如每个线程用独立 StringBuilder + 合理预分配。
- 别因为“线程安全”就默认选
StringBuffer，先确认是否真要共享实例 -
capacity相关方法（如ensureCapacity、trimToSize）两者都支持，行为无差异 - Android 上
StringBuilder在低版本有兼容性坑（如 API 19 前某些 ROM 对trimToSize实现不一致），但纯 Java SE 环境不用操心
什么时候干脆别用StringBuilder，换别的方案
当拼接逻辑固定、编译期可知，或者数据结构明确时，StringBuilder 反而是累赘。JVM 对字符串字面量拼接、String.concat、甚至 String.join 都有专门优化。
常见错误现象：写一堆 sb.append("key=").append(key).append("&val=").append(val)，其实用 String.format 或 MessageFormat 更清晰；或者用 String.join(",", list) 替代手写循环 append。
- 两个字符串拼接：直接用
+，javac 会自动转成StringBuilder，且常量折叠后可能直接优化成字面量 - 集合拼接：优先用
String.join，它内部用StringBuilder且做了容量预估（基于CharSequence.length()总和） - 格式化场景：避免手动
append拼 URL 或 SQL，用java.net.URLEncoder或参数化 PreparedStatement
预分配 capacity 看似简单，但得知道它挡不住逻辑错误——比如误把 sb.toString() 放在循环里反复调用，或在多线程里共享没同步的实例。这些比少写一个参数影响大得多。
