为何比new快12倍)
1. 一个被忽视的细节引发的性能思考
前几天在做一个日志聚合模块的时候，碰到一个挺有意思的问题。当时需要在一个循环里反复拼接字符串，量级大概在百万次左右，用的当然是StringBuilder。代码逻辑本身不复杂，但跑完压测之后发现，光是“清空缓冲区”这个动作，就吃掉了将近 8% 的 CPU 时间片。这个比例说实话有点超出我的预期，因为在我的固有印象里，清空一个StringBuilder不就是一行代码的事吗？
后来我把几种常见的清空方式拉出来做了个对比测试，结果发现不同写法之间的差距，在高频调用场景下会被放大得非常明显。这件事让我意识到，StringBuilder的清空操作虽然看起来是个再基础不过的知识点，但真正把它讲透、把每种方式的适用边界说清楚的文章并不多。大部分资料要么只给结论不给数据，要么就是简单罗列几种写法，缺少对底层机制的解释。
所以这篇文章我打算把这件事彻底聊清楚。核心关键词就是StringBuilder 清空方式、Java 字符串拼接、性能效率对比。我会把四种主流清空方式的原理、写法、内存行为、效率差异全部拆开来讲，并且给出我实测的数据和结论。不管你是刚接触 Java 的新手，还是写了几年业务代码的老手，只要你的项目里存在循环拼接字符串的场景，这篇内容应该都能帮你避开一些坑。
四种方式分别是：setLength(0)、delete(0, length())、new StringBuilder()重新创建、以及replace(0, length(), "")。下面我会逐一分析它们的实现机制，然后给出对比测试的完整方案和结果。
2. 四种清空方式的核心机制拆解
2.1 setLength(0) 到底做了什么
setLength(0)是我个人最常用的一种方式，也是绝大多数场景下的首选。它的实现逻辑非常直接：把StringBuilder内部的count字段直接设置为 0。
在AbstractStringBuilder这个父类里，count是一个int类型的字段，记录当前字符数组中实际有效的字符数量。注意，它记录的不是数组容量，而是有效长度。当你调用setLength(0)的时候，源码做的事情大致是这样的：先检查传入的newLength是否合法（不能为负数），然后如果newLength小于当前count，就把从newLength到count之间的字符全部置为\0，最后把count赋值为newLength。
这里有个细节值得注意：它会把废弃位置的字符置空。这个操作的意义在于帮助垃圾回收器识别这些位置不再被引用，虽然对于char这种基本类型来说影响不大，但从代码设计的一致性角度看是合理的。
关键点在于，setLength(0)不会释放底层数组。原来扩容到多大的char[] value，清空之后还是那么大。这意味着如果你之前拼接了一个很长的字符串导致数组扩容到了 8192，调用setLength(0)之后，这个 8192 的数组依然保留着，下次拼接的时候可以直接复用，不需要重新分配内存。
提示：
setLength(0)之后，capacity()返回的值不变，length()返回 0。这两个方法的区别一定要分清楚，后面排查问题的时候经常用到。
2.2 delete(0, length()) 的边界处理
delete(int start, int end)这个方法的本意是删除指定区间内的字符。当你传入delete(0, sb.length())的时候，效果上等同于清空整个缓冲区。
它的内部实现比setLength(0)要复杂一些。首先会做一系列的边界检查，比如start不能小于 0，end不能大于length()，start不能大于end等等。然后计算需要移动的字符数量，调用System.arraycopy把end之后的字符往前挪。由于end正好等于length()，所以实际上没有字符需要移动，arraycopy的源和目标区间长度为 0。
最后它会把count减去被删除的长度，也就是把count设置为 0。同时也会把废弃位置置空。
从最终效果看，delete(0, length())和setLength(0)达到的状态是一样的：count为 0，底层数组保留。但前者多了一系列边界检查和方法调用的开销。在单次调用的层面这个开销微乎其微，但在百万次级别的循环里，累积起来就不容忽视了。
另外有一个容易踩的坑：如果你写成delete(0, sb.length() - 1)，那就会残留最后一个字符。这种 off-by-one 的错误在代码 review 的时候经常被漏掉，因为大部分时候结果看起来“差不多对”。
2.3 new StringBuilder() 的内存代价
直接重新创建一个StringBuilder对象，这是最“暴力”也最直观的方式。老对象失去引用之后等待垃圾回收，新对象从零开始。
这种方式的优势是代码极其清晰，没有任何歧义。但代价也很明显：每次创建新对象都要分配一块默认容量为 16 的char[]数组，同时对象头本身也占用内存。在循环里频繁 new 的话，会给年轻代带来不小的压力，触发Minor GC的频率会明显上升。
我做过一个粗略的估算：一个空的StringBuilder对象，对象头加上char[]数组的引用，再加上数组对象本身的开销，在 64 位 JVM 上大约占用 40 到 48 字节（开启压缩指针的情况下）。如果你在循环里 new 一百万次，那就是大约 40 到 48 MB 的临时对象需要被回收。这个量级在年轻代里不算小，尤其是在年轻代空间配置不大的情况下，GC 次数会显著增加。
当然，如果你的清空操作频率很低，比如每个请求处理一次，那 new 的方式完全没问题，代码可读性反而更好。关键是要根据调用频率来判断。
2.4 replace(0, length(), "") 的隐藏开销
replace(int start, int end, String str)这个方法的设计目标是替换区间内容。当你传入空字符串的时候，效果上也是清空。
但它的实现路径是四种方式里最长的。它需要先检查str是否为 null，然后计算替换后的新长度，确保容量足够，接着做字符数组的移动操作，最后更新count。即使替换内容是空字符串，这些检查步骤一个都不会少。
更关键的是，replace内部会调用ensureCapacityInternal来确保容量，虽然大多数时候不会触发实际扩容，但方法调用的开销是实打实存在的。而且它涉及到String对象的参数传递，虽然空字符串是常量池里的对象，但参数传递本身也有成本。
从语义上讲，用replace来清空本身就是一种“借用”，可读性上不如setLength(0)直观。我在代码 review 的时候如果看到这种写法，一般会建议改掉。
3. 效率对比测试的完整方案与数据
3.1 测试环境与基准设计
为了得到有参考价值的数据，我设计了一套基准测试。测试环境是 JDK 17，运行在 Linux 上，JVM 参数保持默认，堆内存设置为 2GB。测试框架用的是 JMH（Java Microbenchmark Harness），这是目前 Java 领域做微基准测试最靠谱的工具，能有效避免 JIT 预热、死代码消除等干扰因素。
测试用例的设计思路是这样的：模拟一个典型的循环拼接场景，每次循环先往StringBuilder里追加一定量的内容，然后清空，再进入下一轮。分别测试四种清空方式在不同数据量级下的表现。
具体参数设置如下：
| 参数项 | 设置值 | 说明 |
|---|---|---|
| 预热轮次 | 5 轮 | 每轮 1 秒，让 JIT 充分编译 |
| 测量轮次 | 10 轮 | 每轮 1 秒，取平均值 |
| Fork 次数 | 3 次 | 每次独立 JVM，减少偶然误差 |
| 单次追加内容 | 128 字符 | 模拟中等长度的日志行 |
| 循环次数 | 每轮操作内 1000 次 | 控制单次测量时长 |
| 线程数 | 单线程 | 排除并发干扰 |
测试的四种方法分别封装成独立的 benchmark 方法，方法体内部只保留清空操作，追加操作统一放在循环开头，确保对比的公平性。
3.2 实测数据与结果解读
跑完测试之后，我把结果整理成了下面这张表。数据是三次 Fork 的平均值，单位是微秒每千次操作（越低越好）。
| 清空方式 | 平均耗时（μs/1000次） | 相对基准 | 内存分配（MB/百万次） |
|---|---|---|---|
| setLength(0) | 12.4 | 1.00x | 0 |
| delete(0, length()) | 18.7 | 1.51x | 0 |
| new StringBuilder() | 156.3 | 12.60x | 约 44 |
| replace(0, length(), "") | 31.2 | 2.52x | 0 |
这组数据有几个点值得展开说。
setLength(0)毫无悬念地拿了第一，而且优势明显。它的操作本质上就是一次字段赋值加上一次数组填充（把废弃位置置零），JIT 编译之后这些操作会被优化得非常紧凑。
delete(0, length())排在第二，大约是setLength(0)的 1.5 倍耗时。多出来的开销主要来自边界检查和方法调用链。虽然arraycopy的实际拷贝长度为 0，但方法调用的框架开销依然存在。
replace(0, length(), "")是setLength(0)的 2.5 倍左右。它的调用链最长，中间涉及String参数的处理和容量检查，累积开销比较明显。
new StringBuilder()的数据最夸张，是setLength(0)的 12 倍以上。而且它还有额外的内存分配，百万次操作产生约 44MB 的临时对象。这个数字和我前面估算的基本吻合。
注意：这个测试是在单线程、无竞争的理想条件下做的。如果你的场景涉及多线程，
new StringBuilder()的 GC 压力会进一步放大，因为多线程环境下年轻代的分配和回收竞争会更激烈。
3.3 不同数据量级下的表现差异
上面的测试用的是 128 字符的追加量。我又额外测了 16 字符和 1024 字符两种情况，想看看数据量对清空效率有没有影响。
结论是：清空操作本身的耗时和数据量基本无关。因为四种方式在清空时都不涉及实际的数据搬移（delete和replace在清空场景下拷贝长度为 0），所以追加内容的多少不影响清空的开销。
但有一个间接影响值得注意：如果你追加的内容很长，导致StringBuilder的底层数组扩容到了很大的尺寸，那么用new StringBuilder()方式的话，新对象会从默认容量 16 重新开始，下次拼接又得经历一轮扩容。而setLength(0)保留了已经扩容好的数组，下次拼接直接复用，省掉了扩容时的数组拷贝。这个差异在“拼接-清空”循环里会体现得非常明显。
我实测过一组数据：追加 1024 字符、循环 1000 次的情况下，setLength(0)的总耗时比new StringBuilder()低了将近 40%，因为后者每次都要重新经历从 16 到 1024 的多次扩容。
4. 不同场景下的选型建议与避坑指南
4.1 循环拼接场景：首选 setLength(0)
如果你的代码结构是“在循环里反复拼接字符串，每次拼完取结果然后清空”，那setLength(0)是唯一合理的选择。它保留了底层数组的容量，避免了重复扩容，同时清空操作本身的开销最小。
这里有一个实操细节：如果你能预估到单次拼接的最大长度，可以在创建StringBuilder的时候就指定初始容量，比如new StringBuilder(4096)。这样在整个循环过程中，数组一次扩容都不需要，性能会进一步优化。
// 推荐写法：预估容量 + setLength(0) 复用 StringBuilder sb = new StringBuilder(4096); for (LogEntry entry : entries) { sb.append(entry.format()); String line = sb.toString(); // 处理 line sb.setLength(0); }注意toString()会创建一个新的String对象，这个开销是不可避免的，因为你需要把结果传出去。但setLength(0)本身不产生任何新对象。
4.2 低频清空场景：可读性优先
如果你的StringBuilder清空操作频率很低，比如每个 HTTP 请求处理一次，或者每个文件处理一次，那么用new StringBuilder()完全没问题。代码清晰易懂，性能差异在这个量级下可以忽略不计。
我个人的判断标准是这样的：如果清空操作的调用频率低于每秒一万次，四种方式随便选，挑你觉得最好读的就行。如果高于每秒十万次，那就老老实实用setLength(0)。中间这个区间，建议用setLength(0)，因为改动成本很低，但收益是确定的。
4.3 多线程环境下的额外考量
StringBuilder本身不是线程安全的，这一点大家都知道。但我想说的是，在多线程环境下，清空方式的选择会带来额外的间接影响。
如果你用new StringBuilder()的方式，每个线程每次清空都创建新对象，这些对象都在年轻代分配。多线程同时分配会加剧 TLAB（Thread Local Allocation Buffer）的竞争，虽然 JVM 在这方面做了很多优化，但在高并发场景下，分配速率的上升依然会推高 GC 频率。
而setLength(0)不产生新对象，对 GC 完全透明。所以在多线程场景下，setLength(0)的优势比单线程更大。
当然，如果你需要线程安全的字符串拼接，应该用StringBuffer而不是StringBuilder。StringBuffer的清空方式选择逻辑和StringBuilder是一样的，setLength(0)同样是首选。
4.4 常见误区与排查技巧
在实际项目里，我见过几种典型的误用，这里列出来供大家参考。
第一种是sb.delete(0, sb.length() - 1)，这种 off-by-one 的错误会导致每次清空后残留一个字符。如果这个残留字符恰好是分隔符或者换行符，可能在很长一段时间里都不会被发现，直到某天下游系统报数据格式错误才暴露出来。
第二种是在setLength(0)之后继续用旧的toString()结果。toString()返回的是一个新的String对象，和StringBuilder后续的修改没有关系。但有些人会误以为toString()返回的是视图，清空StringBuilder之后String也会变空。这个理解是错误的，需要特别注意。
第三种是混淆capacity()和length()。setLength(0)之后length()是 0，但capacity()还是原来的值。如果你用capacity()来判断是否需要清空，逻辑就会出错。
排查这类问题的时候，我通常会在清空操作前后各打一条日志，输出length()和capacity()的值。如果length()没有归零，那说明清空方式有问题；如果capacity()在循环中持续增长，那说明可能存在内存泄漏的风险。
| 常见问题 | 现象 | 排查方法 | 解决方案 |
|---|---|---|---|
| 清空不彻底 | 结果字符串开头有残留 | 检查 delete 的 end 参数 | 改用 setLength(0) |
| 内存持续增长 | capacity 只增不减 | 打印 capacity 变化 | 检查是否有地方持有旧引用 |
| GC 频率过高 | Minor GC 次数异常 | 用 JFR 或 GC 日志分析 | 改用 setLength(0) 复用对象 |
| 结果不符合预期 | toString 后内容为空 | 确认清空和 toString 的顺序 | 先 toString 再清空 |
5. 底层源码视角的补充分析
5.1 AbstractStringBuilder 的字段布局
要真正理解四种清空方式的差异，有必要看一下AbstractStringBuilder的字段定义。它有两个核心字段：char[] value和int count。value是实际存储字符的数组，count是有效字符数。
在 JDK 9 之后，value的类型从char[]变成了byte[]，配合一个byte coder字段来标识编码方式（LATIN1 或 UTF16）。这个变化对清空操作的影响不大，因为清空本质上只是操作count字段，不涉及编码转换。
setLength(0)的源码逻辑非常简洁：检查参数合法性，如果新长度小于当前长度，就把多余位置置零，然后更新count。整个过程没有方法调用嵌套，JIT 编译后基本就是几条机器指令。
delete的源码就复杂一些，它需要处理start和end的各种边界情况，计算移动长度，调用System.arraycopy，最后更新count。虽然清空场景下arraycopy的实际拷贝长度为 0，但方法调用的框架开销和边界检查的指令依然存在。
5.2 JIT 编译对清空操作的影响
JMH 测试之所以要求充分预热，就是因为 JIT 编译对方法性能的影响非常大。setLength(0)这种简单方法在预热几轮之后就会被内联，方法调用的开销完全消失，剩下的就是纯粹的字段操作。
delete和replace因为方法体较大，内联的难度更高，可能无法被完全内联。这意味着在热点代码里，它们的方法调用开销会一直存在。
new StringBuilder()涉及对象分配，JIT 的逃逸分析在某些情况下可以优化掉分配，但在循环里创建对象并被外部引用的情况下，逃逸分析通常无法生效，分配开销是实打实的。
这也解释了为什么 JMH 测试里setLength(0)的优势那么明显——它是最容易被 JIT 优化到极致的一种写法。
5.3 容量保留策略的长期收益
setLength(0)保留底层数组容量的这个特性，在长期运行的循环里收益是复利式的。第一次拼接可能需要经历几次扩容，但一旦数组扩容到足够大，后续所有循环都不再需要扩容。而new StringBuilder()每次都要从零开始，扩容开销反复发生。
我做过一个简单的模拟：拼接 1000 字符的内容，循环 10000 次。setLength(0)方式下，扩容只发生在前几次循环，之后数组稳定在 1024 或 2048 的容量。new StringBuilder()方式下，每次循环都要经历从 16 到 1024 的扩容过程，大约需要 7 次数组拷贝。10000 次循环就是 70000 次额外的数组拷贝，这个开销累积起来相当可观。
所以选型的时候不能只看单次清空操作的耗时，还要把扩容的间接成本算进去。这也是为什么我在所有推荐里都把setLength(0)放在第一位。
6. 我个人的实操体会
这套对比测试做完之后，我把项目里所有循环拼接场景的StringBuilder用法都过了一遍，把new StringBuilder()和delete的写法统一改成了setLength(0)，并且在创建时加上了容量预估。改完之后压测，日志模块的 CPU 占用下降了大约 6 个百分点，GC 日志里年轻代的回收频率也明显降低。
有一个小技巧分享给大家：如果你不确定预估容量设多少合适，可以先设一个偏大的值，比如 8192，然后观察capacity()在运行时的变化。如果发现capacity()一直稳定在初始值，说明预估偏大，可以适当调小；如果发现capacity()在增长，说明预估偏小，需要调大。这个观察过程跑一轮压测就能完成，成本很低。
另外，如果你的项目用的是 JDK 9 以上的版本，StringBuilder的底层实现从char[]换成了byte[]，内存占用大约减半。这意味着同样容量的StringBuilder，在 JDK 9+ 上占用的内存更少，setLength(0)保留容量的策略收益也更大。如果你的项目还在 JDK 8，升级到 JDK 11 或 17 之后，这部分内存开销会自动优化，不需要改代码。
最后说一个我踩过的坑：有一次我在一个工具类里把StringBuilder定义成了静态字段，想着可以复用。结果在多线程环境下出现了数据错乱，因为StringBuilder不是线程安全的。后来改成了每个线程用ThreadLocal持有自己的实例，配合setLength(0)复用，既保证了线程安全，又保留了性能优势。这个模式在需要高频拼接的场景下非常实用，推荐大家试试。
