Java StringBuffer扩容机制疑问：初始容量不足时为何逻辑有差异？

这问题问得太细致了，我刚接触StringBuffer的时候也被这个看似“矛盾”的扩容逻辑搞懵过，咱们结合源码和你的测试案例一步步拆解清楚。

首先要明确：StringBuffer的扩容逻辑其实继承自它的父类AbstractStringBuilder，核心逻辑在ensureCapacityInternal和newCapacity方法里，咱们先看关键的源码片段：

// AbstractStringBuilder中的扩容核心方法
private void ensureCapacityInternal(int minimumCapacity) {
    if (minimumCapacity - value.length > 0) {
        value = Arrays.copyOf(value, newCapacity(minimumCapacity));
    }
}

private int newCapacity(int minCapacity) {
    // 先尝试扩容为 当前容量*2 + 2
    int newCapacity = (value.length << 1) + 2;
    // 如果这个新容量仍然满足不了需求，直接用最小需要的容量
    if (newCapacity - minCapacity < 0) {
        newCapacity = minCapacity;
    }
    // 处理极端溢出情况（一般业务场景很少碰到）
    return (newCapacity <= 0 || MAX_ARRAY_SIZE - newCapacity < 0)
        ? hugeCapacity(minCapacity)
        : newCapacity;
}

接下来结合你的两个测试案例逐一分析：

第一个测试案例：初始容量11，追加"Hello World!"（长度12） #

1. 初始时，StringBuffer内部的字符数组长度（也就是capacity）是11，当前字符串长度length()是0
2. 调用append("Hello World!")后，需要的最小容量是 当前length(0) + 追加字符串长度(12) = 12
3. 因为12 > 当前容量11，触发扩容逻辑
4. 计算新容量：11*2 + 2 = 24
5. 24 > 12（最小需要的容量），所以最终容量确定为24
6. 最终输出12 24，和你的测试结果一致

第二个测试案例：初始容量10，追加"Hello World!"（长度12） #

1. 初始时，内部字符数组长度是10，当前length()是0
2. 追加后需要的最小容量是 0 + 12 = 12
3. 12 > 当前容量10，触发扩容
4. 计算新容量：10*2 + 2 = 22
5. 22 > 12，所以最终容量确定为22
6. 最终输出12 22，和你的测试结果一致

纠正你的误解 #

你之前以为是“长度的两倍”或者“长度加初始容量”，其实都不对，核心规则是：

• 优先扩容为「当前容量 × 2 + 2」
• 只有当这个值小于需要的最小容量时，才会直接把容量设为最小容量

举个极端例子验证：如果初始容量是5，追加一个长度20的字符串：

StringBuffer str = new StringBuffer(5);
str.append("HelloWorldHelloWorld"); // 长度20
System.out.println(str.length() + " " + str.capacity()); // 输出20 20

这时候计算5*2+2=12，12 < 20，所以直接把容量设为20，满足最小需求。

总结扩容步骤 #

1. 计算最小需要容量：当前字符串长度 + 要追加的内容长度
2. 如果最小容量 > 当前内部数组容量，触发扩容
3. 先尝试将容量扩容为「当前容量 × 2 + 2」
4. 若该值仍小于最小容量，则直接将容量设为最小容量
5. 最后处理容量溢出的极端场景（超过Java数组最大容量限制）

内容的提问来源于stack exchange，提问作者Kaustubh Srivastava