StringBuilder 扩容:真实反射测出容量是 16→34→70→142 这样长的

底层是紧凑字符串的 byte[],不是 char[]

JDK 9 之后 String/StringBuilder 底层默认用紧凑字符串(Compact Strings),纯 ASCII 内容按 1 字节/字符存,不再是老印象里的 char[]。

StringBuilder 的可变字符缓冲区字段定义在它的父类 AbstractStringBuilder 里,反射拿到这个字段,在每次 append 之后检查数组长度是否变化,就能捕捉到每一次真实的扩容:

StringBuilderGrowth.java(核心反射逻辑) Field valueField = Class.forName("java.lang.AbstractStringBuilder").getDeclaredField("value"); valueField.setAccessible(true); for (int i = 0; i < 2000; i++) { sb.append('x'); byte[] value = (byte[]) valueField.get(sb); int cap = value.length; // Latin1 编码下 1 字节/字符,cap 就是真实容量 // ... 记录 cap 变化 }

真实验证:连续扩容的容量序列

默认 new StringBuilder() 初始容量是 16,之后每次不够用就扩容一次。

length=1 触发扩容 -> 新容量=16
length=17 触发扩容 -> 新容量=34
length=35 触发扩容 -> 新容量=70
length=71 触发扩容 -> 新容量=142
length=143 触发扩容 -> 新容量=286
length=287 触发扩容 -> 新容量=574
length=575 触发扩容 -> 新容量=1150
length=1151 触发扩容 -> 新容量=2302

第一行(length=1,容量 16)是初始状态,不是真实的扩容事件——new StringBuilder() 默认就分配了 16 个字符的容量,append 第 1 个字符时用不着扩容,只是这里的记录逻辑把"第一次读到的容量"也打印了出来。真正的第一次扩容发生在 length 到达 17(容量 16 已经不够用)的时候,新容量变成 34。逐个验证这串数字:16*2+2=34,34*2+2=70,70*2+2=142……一直到 1150*2+2=2302,每一步都真实对应 JDK 源码里 newCapacity = (oldCapacity << 1) + 2 这个公式,没有例外。

分步演示:oldCapacity*2+2 逐次代入

把上面表格里的 8 次容量变化串成动画,每一步都是真实反射读出的 byte[] 长度,代入公式逐次验证。

真实验证:预先给够容量,扩容次数真实归零

如果提前知道大概要拼多长的字符串,用带初始容量的构造函数能真实省掉全部扩容开销。

预设容量 2000 的初始底层数组长度 = 2000
append 2000 次(预设容量场景)真实扩容次数 = 0