不是。ensurecapacity() 调用越多越不好，只在容量不足时扩容，否则空转；应初始化时设足容量或仅预估后调一次，避免循环中反复调用导致性能下降。
StringBuilder.ensureCapacity() 是不是调用越多越好？
不是。反复调用 ensureCapacity() 不仅没收益，还会白跑几次比较和分支判断——它只在当前容量不足时才扩容，否则直接返回。频繁预估失误、反复调用，等于用 CPU 换来一次空操作。
真正该做的是：在创建 StringBuilder 时就尽量给足初始容量，或在明确知道后续拼接总长时，只调用一次 ensureCapacity()。
- 常见错误现象：
for循环里每次拼接前都调ensureCapacity(currentLen + addLen)，结果发现性能没提升，反而略降 - 使用场景：适合在批量拼接前（如解析 CSV 行、组装 JSON 字段列表）预估总长度后一次性预留
- 参数差异：
ensureCapacity(minimumCapacity)中的minimumCapacity是「字符数」，不是字节数；若预估为 1024，但实际拼出 1025 个字符，仍会触发扩容
怎么预估 StringBuilder 的合理初始容量？
靠猜不如靠结构。如果拼接内容来自固定模板 + 可变字段（比如日志格式 "[{}][{}] {}"），就把模板长度 + 各字段最大可能长度加起来；如果是读取多行字符串拼接，先统计行数和平均行长再乘个 1.2 的余量更稳妥。
别用 new StringBuilder(0) 或默认无参构造——那会初始化为 16 字符容量，小数据还行，稍大一点（比如拼 200 字符）就得扩容三次（16→34→70→142）。
立即学习“Java免费学习笔记（深入）”；
- 示例：拼接 100 条形如
"id=123,name=abc,age=25"的记录，每条最长 30 字符，加上分隔符"\n"，预估：100 × (30 + 1) = 3100 → 取 3200 更安全：new StringBuilder(3200) - 性能影响：初始容量设对，可减少 2–4 次数组复制（每次扩容约 1.5 倍增长）；设太大会浪费堆内存，但通常远小于频繁复制的开销
- 兼容性无坑：所有 JDK 版本行为一致，
ensureCapacity()在 JDK 9+ 也没改逻辑
ensureCapacity() 和 trimToSize() 能一起用吗？
能，但没必要连用。两者目标相反：ensureCapacity() 是“向上保底”，trimToSize() 是“向下收缩”。拼接完成后调 trimToSize() 确实能释放冗余空间，但前提是这个 StringBuilder 后续只读不写——一旦再追加，又得扩容。
更常见的误用是：拼一半就 trimToSize()，接着再拼，结果刚缩完又扩，白忙活。
- 错误现象：
sb.append("a"); sb.trimToSize(); sb.append("b");→ 第二次append触发扩容，因内部数组已被缩到 1 - 正确节奏：只在最终确定不再修改时调
trimToSize()；若中间需复用，不如一开始就按上限配好容量 - 注意点：
trimToSize()不影响length()，只改capacity()；调完后capacity() == length()
为什么 ensureCapacity() 有时没阻止 ArrayIndexOutOfBoundsException？
它根本不会阻止。这个异常通常来自你绕过了 StringBuilder 的安全边界，比如反射修改了内部 value 数组，或用了 getChars() / setCharAt() 传入越界索引——ensureCapacity() 只管扩容，不管访问合法性。
另一个隐蔽原因：多线程共用同一个 StringBuilder 实例。它不是线程安全的，ensureCapacity() 和后续 append() 之间可能被其他线程插入操作，导致实际长度超预期。
- 典型错误：
sb.ensureCapacity(1000); // 线程 A→sb.append(data); // 线程 B 先执行了→sb.append(data); // 线程 A 再执行，越界 - 解决办法：单线程场景下检查索引是否
；多线程必须加锁，或换用 <code>StringBuffer（但性能更低） - 关键提醒：
ensureCapacity()不是线程同步机制，它不做任何锁或 volatile 保障
