1. 字符串拼接的两种姿势到底差在哪刚入行那会儿我写代码拼接字符串从来不动脑子清一色用。直到有一次处理一批日志数据循环体里跑了大概八万次字符串累加程序直接卡成了幻灯片内存曲线像坐了火箭一样往上窜。当时我还以为是数据库查询拖了后腿排查了大半天才发现罪魁祸首就是那个看起来人畜无害的加号。字符串拼接这件事说小也小小到一行代码就能搞定说大也大大到能直接影响一个系统的吞吐量和内存占用。和StringBuilder.append这两个东西几乎每个写代码的人都用过但真正能说清楚它们底层差异、知道什么场景该用哪个的人其实没想象中那么多。这篇文章就是想把这件事彻底聊透从内存模型讲到字节码指令从循环拼接讲到编译器优化再配上我实际踩过的坑和压测数据让你看完之后能拍着胸脯说这个场景我知道该用哪个。不管你是刚学编程的新手还是写了几年业务代码的老手只要你的日常工作中涉及字符串处理这篇内容都值得花时间过一遍。因为字符串拼接的性能问题往往不是“能不能跑”的问题而是“跑得好不好”的问题而后者恰恰是区分普通代码和高质量代码的分水岭。2. 先搞懂字符串在内存里到底长什么样2.1 不可变对象这个设定是一切讨论的起点要理解和StringBuilder的差异必须先接受一个前提在主流编程语言里字符串通常是不可变对象。什么意思呢就是你创建一个字符串之后它的内容就定死了你没办法在原对象上做任何修改。你写的每一行看起来像“修改”的代码本质上都是在创建一个全新的字符串对象。拿一个最简单的例子来说。你写String s hello;内存里就多了一个内容为 hello 的对象。接着你写s s world;很多人直觉上以为是在原来的 hello 后面接上了 world但实际上发生的事情是系统先创建了一个新的字符串对象内容是 hello world然后把这个新对象的引用赋给了变量 s原来那个 hello 对象如果没人再用就等着被垃圾回收。这个机制带来的直接后果就是每一次拼接都可能产生一个新的对象。拼接次数少的时候无所谓多创建几个对象而已现代垃圾回收器处理起来毫无压力。但一旦拼接发生在循环里或者拼接的字符串本身很长那对象创建的数量就会呈线性甚至指数级增长内存压力和垃圾回收压力就会变得非常可观。2.2 用加号拼接时编译器到底背着你做了什么很多人以为就是简单地把两段字符接在一起其实编译器在背后做了不少事情。以 Java 为例当你写String result a b c;的时候编译器在早期版本里会把它翻译成类似这样的逻辑先创建一个 StringBuilder把 a 追加进去再追加 b再追加 c最后调用 toString 返回结果。注意这里的关键点编译器确实用了 StringBuilder但它是在每一次拼接表达式里新建一个。也就是说如果你写的是result result a b;放在循环里那么每一轮循环都会创建一个新的 StringBuilder 对象追加完内容之后再销毁。循环一万次就创建和销毁一万个 StringBuilder。这个开销在循环次数少的时候可以忽略但循环次数一上来问题就暴露了。后来编译器做了一些优化比如在 JDK 9 之后引入了 invokedynamic 指令来优化字符串拼接底层用的是 StringConcatFactory会根据实际情况选择更高效的策略。但万变不离其宗核心问题依然是在循环里用加号拼接每次循环都会产生额外的中间对象。2.3 StringBuilder 的设计思路用一个可变容器来攒内容StringBuilder 的思路就完全不一样了。它内部维护了一个可变的字符数组你每次调用 append它就把新内容追加到这个数组的末尾。只要数组容量够就不会创建新对象。等所有内容都追加完了调用一次 toString把最终结果一次性生成出来。这个设计的好处非常直观不管你在循环里 append 多少次中间过程几乎不产生额外的字符串对象只有最后 toString 的时候才生成一个最终对象。内存分配次数从“每次拼接都分配”变成了“只在扩容和最终输出时分配”差距在数据量大的时候非常明显。而且 StringBuilder 的 append 方法返回的是它自己所以你可以链式调用写起来也很顺手。比如sb.append(a).append(b).append(c)一行代码就能追加多个内容可读性并不比加号差。2.4 一张表看清两者的本质区别对比维度加号拼接StringBuilder.append对象创建频率每次拼接都可能创建新对象仅在扩容和 toString 时创建内存占用随拼接次数线性增长相对稳定取决于容量策略循环场景表现数据量大时急剧下降基本保持稳定代码可读性简洁直观链式调用也还算清晰线程安全性不涉及共享状态时安全非线程安全多线程需换 StringBuffer适用场景少量、固定的拼接循环、大量、动态的拼接这张表不是让你死记硬背而是帮你建立一个判断框架。看到拼接需求的时候先问自己两个问题拼接次数大概多少拼接发生在循环里吗这两个问题的答案基本就能决定你该用哪个。3. 循环拼接的性能差距用数据说话3.1 我做过的一组对比测试光讲理论不够直观我拿一段实际代码跑了一组对比。测试逻辑很简单分别用加号和 StringBuilder 拼接一万次、五万次、十万次记录耗时和内存分配情况。测试环境是一台普通的开发机JDK 版本是 17堆内存给了 512MB。测试代码大致是这样的// 加号方式 String result ; for (int i 0; i count; i) { result result item i; } // StringBuilder 方式 StringBuilder sb new StringBuilder(); for (int i 0; i count; i) { sb.append(item).append(i); } String result sb.toString();跑出来的结果让我印象很深。一万次的时候两者差距还不算夸张加号大概慢了三四倍。但到了十万次加号方式的耗时直接飙到了 StringBuilder 的几十倍而且 GC 日志里能看到频繁的 Young GC每次 GC 的停顿时间虽然不长但架不住次数多整体响应时间被拉得很长。3.2 为什么差距会这么大差距的根源在于中间对象的数量。加号方式在每一轮循环里都会创建一个新的字符串对象这个对象的内容是“上一轮的结果 本轮的新内容”。第一轮创建一个长度为几的对象第二轮创建一个更长的第三轮再创建一个更长的……到第 N 轮的时候每创建一个新对象都要把前面所有内容复制一遍。这就导致了一个很尴尬的局面总复制量不是 N而是 123...N也就是 N 的平方级别。十万次循环复制量就是百亿级别的字符操作这个开销是灾难性的。StringBuilder 则完全不同。它内部的字符数组容量是预先分配好的append 的时候直接往数组后面写只要容量够就不需要复制。即使容量不够需要扩容扩容策略通常也是按倍数增长比如从 16 变成 34再变成 70这样均摊下来每次 append 的复制成本非常低。总复制量是线性的和拼接次数成正比而不是平方关系。3.3 内存分配上的差异同样关键除了 CPU 时间内存分配也是一个大头。加号方式每轮循环都创建一个新字符串这些对象在年轻代里快速堆积垃圾回收器需要频繁地清理它们。虽然单个对象的生命周期很短但数量多了之后GC 的压力会明显上升。StringBuilder 的字符数组虽然也会扩容但扩容次数远少于拼接次数。而且扩容时旧数组会被回收新数组继续用整体内存占用曲线是阶梯式上升的而不是像加号那样一路飙升。提示如果你在循环里用加号拼接而且循环次数超过一千基本就可以考虑换成 StringBuilder 了。这个阈值不是绝对的但可以作为一个粗略的判断标准。3.4 一个容易被忽略的细节字符串常量的编译期优化有一种情况加号拼接其实并不慢那就是编译期就能确定结果的常量拼接。比如你写String s hello world;编译器在编译阶段就会把它直接合并成hello world运行时根本不存在拼接操作。这种情况下用加号完全没问题甚至比 StringBuilder 更简洁。但要注意只有字面量之间的拼接才会触发这个优化。一旦涉及变量比如String s prefix world;编译器就没法在编译期确定结果了只能老老实实在运行时做拼接。很多人误以为所有加号拼接都会被优化这是一个常见的认知偏差。4. 那是不是所有场景都该用 StringBuilder4.1 简单拼接用加号反而更合适看到这里你可能会想既然 StringBuilder 这么强那以后所有拼接都用它不就行了还真不是。代码的可读性和维护成本也是成本而且有时候这个成本比性能成本更值得关注。比如你要拼接一个简单的提示信息String msg 用户 name 的年龄是 age;。这种场景下拼接次数就三四次用加号一行写完清晰明了。如果换成 StringBuilder代码会变成好几行可读性反而下降而性能上的收益几乎为零。这种时候加号是更好的选择。再比如日志输出、异常信息构造、简单的字符串格式化这些场景拼接次数少、不在循环里用加号完全够用。过度使用 StringBuilder 会让代码变得啰嗦反而增加了阅读负担。4.2 判断标准其实就三条我总结了一个简单的判断框架遇到拼接需求的时候按这三条过一遍拼接次数如果拼接次数在十次以内加号通常没问题超过十次开始考虑 StringBuilder。是否在循环里只要拼接发生在循环体内不管循环次数多少优先用 StringBuilder。是否涉及大量动态内容如果拼接的内容来自用户输入、数据库查询、文件读取等运行时才能确定的数据而且数量不确定用 StringBuilder 更稳妥。这三条不是死规矩但能覆盖绝大多数日常场景。真正重要的是养成一个习惯写拼接代码的时候脑子里过一下这个场景的数据量级而不是无脑用加号或者无脑用 StringBuilder。4.3 多线程场景下的额外考量StringBuilder 不是线程安全的。如果多个线程同时往同一个 StringBuilder 里 append可能会出现内容错乱甚至数组越界的问题。这种场景下要么给拼接操作加锁要么换成 StringBuffer。StringBuffer 的方法基本都加了 synchronized线程安全但代价是性能比 StringBuilder 低一些。如果你的场景确实是多线程并发拼接而且对性能有要求可以考虑用 ThreadLocal 给每个线程分配独立的 StringBuilder最后再合并结果。这样既避免了锁竞争又保证了线程安全。不过说实话多线程同时拼接同一个字符串的场景在实际业务里并不多见。大多数时候拼接操作都发生在单个线程的方法内部用 StringBuilder 就足够了。5. 实操中那些容易踩的坑5.1 初始化容量没给对扩容照样拖后腿StringBuilder 默认的初始容量是 16 个字符。如果你要拼接的内容远超这个长度它就会不断扩容。扩容的逻辑通常是“当前容量乘以二再加二”然后把旧数组的内容复制到新数组里。虽然扩容次数比加号方式少得多但如果拼接的内容特别长扩容带来的复制开销依然不可忽视。解决办法很简单在创建 StringBuilder 的时候就预估一个合理的容量。比如你知道最终结果大概有一千个字符那就直接new StringBuilder(1024)这样基本不会触发扩容性能最优。// 不推荐默认容量可能多次扩容 StringBuilder sb new StringBuilder(); // 推荐预估容量减少扩容次数 StringBuilder sb new StringBuilder(1024);预估容量这件事不需要特别精确宁可稍微大一点也不要频繁扩容。多分配一点内存的代价远小于反复复制数组的代价。5.2 在循环里用加号但循环次数很少这是一个比较微妙的情况。比如循环只有三五次用加号拼接其实问题不大但代码审查的时候可能会被同事挑出来说“循环里不要用加号”。这时候要不要改呢我的建议是如果循环次数确实很少而且代码可读性用加号明显更好那就保留加号但加一个注释说明这里循环次数有限。这样既保证了可读性又避免了后续维护者的困惑。如果团队规范明确要求循环里必须用 StringBuilder那就遵守规范毕竟一致性也有价值。5.3 混淆了 StringBuilder 和 String 的 equalsStringBuilder 没有重写 equals 方法所以sb1.equals(sb2)比较的是引用地址而不是内容。如果你需要比较两个 StringBuilder 的内容是否相同要么先 toString 再比较要么用 contentEquals 方法。StringBuilder sb1 new StringBuilder(hello); StringBuilder sb2 new StringBuilder(hello); // 错误比较的是引用 System.out.println(sb1.equals(sb2)); // false // 正确先转成 String 再比较 System.out.println(sb1.toString().equals(sb2.toString())); // true这个坑我在早期项目中踩过一次当时用 StringBuilder 做缓存键结果发现相同的键总是匹配不上排查了半天才发现是 equals 的问题。后来统一改成先 toString 再比较问题就解决了。5.4 拼接 null 值时的行为差异加号拼接遇到 null 的时候会把 null 当成字符串 null 来处理不会抛异常。StringBuilder 的 append 方法遇到 null 时追加的也是 null 这个字符串。这一点两者行为一致但如果你期望的是跳过 null 或者用空字符串代替就需要自己手动判断。String a null; String result a test; // 结果是 nulltest StringBuilder sb new StringBuilder(); sb.append(a).append(test); // 结果也是 nulltest如果业务上不希望出现 null 字样记得在拼接前做判空处理。这个细节在日志输出和用户提示场景里尤其重要因为 null 出现在用户界面上是很不专业的。6. 常见问题速查与排查思路6.1 为什么我用了 StringBuilder 还是慢如果你已经换成了 StringBuilder但性能依然不理想可以从这几个方向排查容量是否合理默认容量太小导致频繁扩容是常见原因。打印一下 StringBuilder 的 capacity 和 length看看扩容了多少次。是否在循环里反复创建 StringBuilder有些人把new StringBuilder()写在了循环体内部这样每轮循环都创建一个新对象等于白换。toString 是否调用过于频繁toString 会创建一个新的字符串对象如果在循环里反复调用开销也不小。应该等所有 append 完成后再调用一次。拼接的内容是否本身就有性能问题比如拼接的内容来自数据库查询或者远程调用那瓶颈可能不在拼接本身。6.2 什么时候该用 String.join 或者 String.format除了加号和 StringBuilder还有一些其他的拼接方式。String.join适合用分隔符连接多个字符串底层也是用 StringBuilder 实现的代码更简洁。String.format适合格式化输出但性能比 StringBuilder 差一些因为涉及解析格式字符串的过程。拼接方式适用场景性能加号少量、固定拼接少量时够用循环里差StringBuilder循环、大量拼接好String.join带分隔符的集合拼接好String.format格式化输出一般StringBuffer多线程拼接中等选择哪种方式取决于你的具体场景。没有银弹只有最合适的工具。6.3 一个实际项目中的优化案例之前接手过一个日志聚合模块原始代码在循环里用加号拼接每条日志的各个字段循环次数大概在几千到几万不等。压测的时候发现这个模块的 CPU 占用特别高GC 频率也明显高于其他模块。优化方案很直接把循环内的加号拼接改成 StringBuilder并且根据日志字段的典型长度预估了一个初始容量。改完之后模块的 CPU 占用下降了大概六成GC 频率也恢复到了正常水平。整个改动只涉及十几行代码但效果立竿见影。这个案例说明一个问题性能优化不一定要做很复杂的事情把最基础的字符串拼接写对就能解决很大一部分问题。6.4 排查字符串拼接问题的通用思路遇到拼接相关的性能问题时我通常按这个顺序排查先看代码里有没有循环内的加号拼接这是最常见的元凶。再看 StringBuilder 的创建位置和初始容量确认没有在循环里反复创建。然后看 toString 的调用时机确认没有在循环里反复转换。最后看拼接内容的来源排除外部数据获取的瓶颈。这个顺序基本能覆盖九成以上的拼接性能问题。剩下的那一成可能需要借助性能分析工具来定位但那是另一个话题了。7. 我个人的一些实操体会写了这么多年代码关于字符串拼接这件事我最大的体会是不要凭直觉写代码要凭场景写代码。加号和 StringBuilder 没有绝对的好坏只有适不适合当前场景。一个简单的提示信息拼接用加号一行搞定清晰又高效一个循环里的数据聚合用 StringBuilder 稳稳当当性能有保障。另一个体会是性能优化要从高频路径入手。字符串拼接的优化尤其如此因为拼接操作往往散落在代码各处你不可能把所有加号都改成 StringBuilder也没必要。把那些在循环里、在热点方法里、在大数据量场景下的拼接改对收益就已经非常可观了。最后分享一个小技巧如果你不确定某个拼接场景该用哪个可以写一个简单的基准测试跑一下。不用很复杂循环个几万次打印一下耗时答案自然就出来了。这比任何理论分析都直接也比任何人的经验都可靠。毕竟数据不会骗人。