怎么利用 StringBuilder.capacity() 预先评估构建器的内部缓冲区大小以减少扩容
capacity() 返回的是当前缓冲区总容量，不是已用长度
这里有个常见的误解：很多人以为 capacity() 返回的是当前字符串的实际长度。其实不然，它告诉你的是内部那个 char[] 数组的总长度——也就是已经分配好、但可能还没填满的空间。举个例子，new StringBuilder("abc") 的 length() 是 3，但它的 capacity() 在 JDK 默认情况下通常是 16。这中间的差值，就是 JVM 为你预留的“余粮”。
真正拖慢速度的，是频繁的扩容操作。每次拼接的字符数超过当前的 capacity()，JVM 就不得不新建一个更大的数组，然后把旧数据全部拷贝过去。所以，如果能预估最终需要多少字符，并在一开始就通过构造函数指定容量，性能表现会比依赖默认的“用多少扩多少”策略稳定得多。
- 默认构造器
new StringBuilder()：容量是 16，只适合拼接非常短的字符串；一旦超过，扩容就开始了。 - 预估长度构造：如果你确定最终会拼接大约 2000 个字符，直接写
new StringBuilder(2048)会更高效（容量向上取整到 2 的幂，对内存管理更友好）。 - 查看与扩容：
capacity()在运行时可以随时调用，但它只是个“观察窗口”，不能直接设置容量。真想扩容，得靠另一个方法：ensureCapacity(int)。
用 ensureCapacity() 主动预留空间，比 let-it-grow 更稳
在构建过程中，如果你能动态估算出最终的总长度（比如，循环拼接 N 条日志，每条平均 L 个字符），那么可以在关键节点调用 ensureCapacity() 来提前分配足够的内存。这个方法很“聪明”：它不会缩小容量，只在当前容量不足时，才会扩容到至少你指定的参数值。
不过，这里有个细节需要注意：多次调用 ensureCapacity() 并不会导致重复分配，JVM 内部有判断逻辑。但反过来，过度预留（比如预估了 10MB，结果只用了 10KB）就会造成堆内存的浪费，尤其是在高并发、对象生命周期短的场景下，这种浪费会被放大。
- 最佳调用时机：推荐在循环开始前，或者首次进行大规模拼接前调用一次，例如
sb.ensureCapacity(expectedTotalLength)。 - 避免无效调用：切忌在循环体内反复调用这个方法，比如
for (int i = 0; i —— 这除了增加方法调用的开销，没有任何实际意义。 - 未知长度的处理：如果完全无法预估总量（比如流式读取未知长度的数据），与其硬猜一个容量，不如考虑使用线程安全的
StringBuffer，或者采用分块处理的策略。
扩容策略和实际内存占用有隐含成本
了解 JDK 的扩容逻辑很重要。在早期版本中，策略大致是：新容量 = 旧容量 × 2 + 2。虽然 JDK 11 之后优化了增长曲线，使其更平滑，但本质上仍是非线性的。这意味着从 16 扩容到 34，再到 70、142… 每一次扩容都伴随着一次数组的创建和全量拷贝。更关键的是，新数组可能会因为大小而直接进入老年代，从而触发额外的 Full GC。
所以，“预估”并不是越精确越好，关键在于留下合理的余量：估得太小，依然免不了扩容；估得太大，又会浪费内存。一个实用的经验法则是：预估长度 × 1.2～1.5，然后向上取整到最近的 2 的幂（比如预估 1000 字符，就分配 1024；预估 3000，就分配 4096）。
- 如何观察扩容：可以通过 JFR (Ja va Flight Recorder) 或添加
-XX:+PrintGCDetailsJVM 参数，观察是否频繁触发 Young GC，这能间接反映出字符串操作的频繁程度。 - 优化有前提：某些 JDK 版本对小字符串对象做了逃逸分析优化，
StringBuilder可能会在栈上分配。在这种情况下，对capacity()的调优收益就非常有限了，切记不要过早优化。 - 最终转换的开销：别忘了，最后调用
sb.toString()时，会新建一个字符数组并进行拷贝。这部分开销是无法通过预先调整capacity()来避免的。
别忽略 substring 和 delete 导致的 capacity 滞后问题
当你调用 delete(0, sb.length()) 或 setLength(0) 来清空内容时，capacity() 的值是保持不变的——底层的缓冲区数组并没有被释放。这其实是设计上的优势，下次拼接时可以直接复用这个数组，避免了反复新建对象的开销。
但是，如果你清空之后，接下来只需要拼接一个极短的字符串（比如几个字符），却仍然背着一个 8192 容量的“大包袱”，那这部分内存就处于闲置状态了。这种情况虽然不常见，但如果你的应用场景明确知道后续拼接规模会急剧下降，同时又非常在意内存占用（例如，在中间件里长期复用的缓冲区），就需要留意了。
一个权衡的做法是主动重建对象：sb = new StringBuilder(16).append(sb)。但这需要你仔细评估对象创建的成本和内存节省的收益。
- 清空方式对比：
setLength(0)速度最快，且保留容量；delete(0, len)效果等同；new StringBuilder()最彻底，但代价也最高。 - 慎用 trimToSize()：不要指望用
trimToSize()来“缩小”容量。它只会把容量收索到当前的length()。如果此时 length 是 0，结果就是 capacity 也变成 0，下次 append 时立刻触发扩容，性能反而更差。 - 适用场景：如果只是线程内的临时拼接，基本不用关心 capacity 滞后问题；但如果是池化复用、需要长期保持的 StringBuilder 对象，就需要关注清空后的状态一致性了。
说到底，预估 capacity 的本质，是在内存占用和数组拷贝开销之间寻找一个平衡点。最容易掉入的思维陷阱，是把“避免任何一次扩容”当作绝对目标，而忘记了 StringBuilder 被设计出来的初衷，就是为了高效、灵活地处理字符串拼接——只要别在循环里无脑地 new StringBuilder()，其他的细节，都有商量的余地。
