该指定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免费学习笔记（深入）”；
- 扩容发生在
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() 放在循环里反复调用，或在多线程里共享没同步的实例。这些比少写一个参数影响大得多。
