StringBuilder动态扩容有明确触发条件、固定公式和可观测开销：当count+新增字符数>value.length时触发，新容量先按oldCapacity×2+2计算，再与最小所需容量取大值，真实开销在于System.arraycopy()的O(n)拷贝。
StringBuilder动态扩容不是“自动变大”，而是有明确触发条件、固定计算逻辑和可观测开销的底层行为。关键在于理解 count（已用长度） 和 value.length（底层数组容量） 的关系：只要 count 小于数组长度，追加就是纯指针移动；一旦 count 等于数组长度，下一次 append 就必然触发扩容。
扩容什么时候发生？
扩容发生在操作执行前的容量校验阶段，不是等操作做完再处理。具体包括：
- append() 时：当前 count + 新增字符数 > value.length
- insert() 时：插入位置索引 + 新增字符数 > value.length（注意不是从末尾算，而是从插入点开始占位）
- replace() 或 delete() 后再次 append：若此时 count 已达当前数组上限，也会立刻扩容
新容量怎么算？
扩容不是简单翻倍，而是两步判断：
- 先按公式算基础容量：newCapacity = oldCapacity × 2 + 2（即
old << 1 + 2） - 再与“最小所需容量”（count + 新增字符数）比较：若基础容量不够，就直接取最小所需容量
- 最终结果不能超过
Integer.MAX_VALUE - 8，否则抛OutOfMemoryError
例如：初始容量 16，追加 20 个字符 → 需求 20 → 计算得 16×2+2=34 ≥ 20 → 实际扩到 34；若追加 50 个字符 → 34 < 50 → 直接扩到 50。
立即学习“Java免费学习笔记（深入）”；
扩容的真实开销在哪？
每次扩容都包含三个不可省略的动作：
- 在堆上分配一块新的 char[] 内存
- 调用
System.arraycopy()把旧数组内容完整复制过去（时间复杂度 O(n)） - 将 value 引用指向新数组，旧数组等待 GC 回收
频繁扩容会产生大量短生命周期 char[] 对象，显著增加年轻代 GC 压力。尤其在循环中逐字符 append('a')，比批量 append("aaaa") 更容易触发多次扩容。
怎么让扩容更可控？
目标不是消灭扩容，而是让它少发生、准发生：
-
预估初始容量：比如拼接 100 条日志，每条平均 75 字符，预留 10% 余量 →
new StringBuilder(8300) - 优先用 append(String) 而非反复 append(char)：减少边界检查次数，也降低扩容频次
-
在可复用场景中缓存实例：如工具方法内用
ThreadLocal<StringBuilder>持有，避免每次调用都新建 16 字节数组 -
运行时监控预留空间：用
capacity() - length()判断是否充足；值长期接近 0，说明快扩容了
