stringbuffer扩容在count+新增长度>value.length时触发，新容量为原长×2+2，不足则直接设为所需最小长度；扩容需数组复制，预分配合理初始容量可避免频繁扩容。
StringBuffer的扩容触发时机
扩容不是按“用了多少”来判断，而是看“要放多少”是否超出当前底层数组长度。具体来说，只要 当前已存字符数（count） + 即将追加/插入的字符长度 > 底层数组长度（value.length），就会触发扩容。比如初始容量16，append一个20字符的字符串，一次就超了；但若分10次append两个字符，前8次不扩容，第9次（count=16）再append时就会触发——因为16+2 > 16。
扩容计算公式与实际增长规律
扩容不是简单翻倍，而是执行：新容量 = 当前数组长度 × 2 + 2。例如：
- 初始16 → 扩容后为 16×2+2 = 34
- 34 → 扩容后为 34×2+2 = 70
- 70 → 扩容后为 70×2+2 = 142
这个+2的设计，是为了避免极小初始容量（如1或2）导致首次扩容后仍不够用，也防止传入0容量时生成非法数组。如果按此公式算出的新容量仍小于实际所需最小长度（比如你要一次性append 200个字符，而当前容量才34），则直接设为所需最小长度，跳过倍增逻辑。
扩容过程本质是数组复制
每次扩容都包含三个不可省略的步骤：
- 分配一块新char[]（或byte[]，JDK9+），大小即计算所得新容量
- 调用
Arrays.copyOf(value, newCapacity)把旧内容逐字拷贝过去 - 将内部
value引用指向新数组，旧数组等待GC回收
这意味着：扩容次数越多，CPU花在内存拷贝上的时间越长，同时产生更多临时对象，加重GC压力。压测中若发现Arrays.copyOf成为热点方法，基本可定位为扩容过频。
预分配容量是最有效的优化手段
不指定初始容量时，默认16，对多数业务场景都偏小。优化关键在于合理预估总长度并留余量：
- 静态拼接（如日志模板）：模板长度 + 各变量最大可能长度（如用户ID最长32、订单号最长64）
- 动态拼接（如CSV解析）：单行平均长度 × 1.2 或直接加固定余量（如+64）
- 避免过度预留：设成5000却只拼200字符，浪费堆内存，反而增加GC负担
构造时写new StringBuffer(256)比默认构造快得多，尤其在循环内反复使用同一实例时——一次预分配，全程零扩容。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
