字符串拼接这件事几乎每个写代码的人都觉得自己会。不就是把两段文字接在一起吗加号一敲就完事了。但我见过太多项目在日志拼装、SQL 组装、大批量文本导出这些场景里因为随手用了加号导致接口响应从几十毫秒涨到几秒CPU 飙高GC 频繁最后排查半天才发现问题出在一行看起来人畜无害的str str item上。这篇内容就围绕这个看似基础、实则暗藏玄机的话题展开把加号和 StringBuilder.append 这两种方式从底层原理、编译期优化、运行时表现到实际选型标准掰开揉碎讲清楚。不管你是刚入行的新手还是写了几年业务代码的老手只要你的项目里存在循环拼接、批量文本处理、动态 SQL 构建这类操作这篇内容都值得你花时间看完。1. 从一段线上告警说起加号到底慢在哪1.1 一个真实的性能劣化场景之前参与过一个数据导出模块的优化功能本身不复杂从数据库分批读取记录把每条记录的若干字段拼成一行文本最后输出成一个大的文本文件。最初的实现非常直白用一个字符串变量不断累加代码大概长这样String result ; for (Record record : recordList) { result result record.getFieldA() , record.getFieldB() \n; }单次导出几百条记录时一切正常响应时间在可接受范围内。但当数据量涨到几万条时接口耗时直接突破十秒监控上能看到明显的 GC 次数激增。当时第一反应是数据库查询慢排查后发现查询只占了几百毫秒真正的耗时全在循环拼接这一段。把加号换成 StringBuilder 之后同样的数据量耗时降到了几百毫秒级别差距接近二十倍。这个案例不是个例。字符串拼接的性能问题有个特点数据量小的时候完全看不出来一旦量级上来劣化是指数级的而不是线性的。很多人因此产生误判觉得我平时用加号也没出过问题直到某天数据量增长问题才突然爆发。1.2 不可变字符串带来的连锁反应要理解加号为什么慢得先回到字符串这个类型的设计本身。在主流语言里字符串通常被设计成不可变对象也就是说一个字符串实例一旦创建它内部承载的字符序列就不能被修改。这个设计带来很多好处比如线程安全、可以安全地作为哈希表的键、便于缓存哈希值等等。但代价是任何看起来像修改字符串的操作本质上都是创建了一个全新的字符串对象。所以当你写下result result record.getFieldA()时运行时实际发生的事情是先读取 result 原有的全部字符再读取新字段的字符在内存里开辟一块新空间把两部分内容复制进去生成一个新的字符串对象最后把这个新对象的引用赋给 result。原来那个 result 对象就此变成垃圾等待被回收。单看一次操作这点开销微不足道。但放到循环里问题就被放大了。假设循环执行 N 次第 i 次拼接时需要复制的字符数量大致正比于前 i-1 次累积的总长度。把所有轮次加起来总的复制量大致是 N 的平方级别。这就是为什么数据量翻倍耗时可能变成四倍甚至更多。1.3 内存分配的隐性成本除了字符复制还有内存分配的成本。每一次拼接都意味着一次新的对象分配。在循环里这意味着短时间内产生大量生命周期极短的临时字符串对象。这些对象会迅速填满新生代内存区域触发频繁的垃圾回收。垃圾回收本身不是免费的。即便是针对新生代的轻量级回收也需要暂停应用线程、扫描存活对象、复制整理内存。当回收频率高到一定程度应用的吞吐量就会明显下降。更麻烦的是如果这些临时对象中有部分因为某些原因存活时间稍长被晋升到了老年代那后续的回收成本会更高甚至可能触发全局停顿。我在排查那个导出模块时特意抓取了 GC 日志能看到在拼接阶段新生代回收几乎每隔一两秒就触发一次而正常业务逻辑下这个间隔是几十秒。这就是典型的对象分配速率过高导致的 GC 压力。提示判断字符串拼接是否是性能瓶颈一个简单的方法是看 GC 日志里新生代回收的频率以及火焰图里字符串相关方法如数组复制、对象分配的占比。如果这两项都偏高基本可以锁定问题。2. 编译器的糖衣加号并非总是那么慢2.1 编译期优化到底做了什么看到这里可能有人会问既然加号这么慢为什么很多资料又说简单的字符串拼接用加号就行这里的关键在于编译器会对加号做一定程度的优化把某些拼接操作自动转换成类似 StringBuilder 的形式。以 Java 为例对于单个表达式里的连续拼接比如String s a b c d;编译器在编译期就会把它改写成创建一个 StringBuilder或类似的辅助对象依次 append 各个部分最后调用 toString。这种情况下加号的实际执行效率和手写 StringBuilder 差别不大因为编译器已经帮你做了转换。这个优化的意义在于它让代码保持了可读性同时避免了简单场景下的性能损失。所以如果你只是在一个表达式里拼接几个固定的变量用加号完全没问题不必为了性能刻意改成 StringBuilder那样反而牺牲了可读性。2.2 循环里的加号为什么优化不掉问题出在循环里。编译器能优化的是单个表达式内部的连续拼接它没法跨循环迭代去复用辅助对象。也就是说下面这段代码String result ; for (int i 0; i n; i) { result result data[i]; }编译器会把它理解成每次循环迭代里都有一个独立的拼接表达式result data[i]。它可以在这一次迭代内部创建一个辅助对象来完成拼接但下一次迭代又会创建一个新的辅助对象。更关键的是每次迭代结束时都要调用 toString 生成最终的字符串赋给 result这个 toString 又是一次完整的字符复制。所以循环里的加号等价于每一轮都新建一个 StringBuilder、append 两个部分、toString 一次、丢弃。累积下来依然是平方级别的复制量和大量的对象分配。编译器帮不了你因为跨迭代的对象复用超出了它的优化范围。2.3 不同语言和版本的差异需要说明的是不同语言、甚至同一语言的不同版本对加号的优化策略并不相同。有些语言的编译器或运行时更激进能识别出循环模式并做优化有些则相对保守。较新的 Java 版本引入了更高效的字符串拼接机制在特定场景下表现优于传统的 StringBuilder但这通常针对的是固定参数个数的拼接循环累加依然需要开发者自己处理。我的建议是不要依赖对编译器优化的猜测来写代码。与其纠结这个版本会不会帮我优化不如在明确知道是循环拼接的场景下直接使用 StringBuilder把控制权握在自己手里。这样无论编译器怎么变代码的性能都是可预期的。场景加号表现StringBuilder 表现推荐选择单个表达式拼接少量变量优编译器优化良需手动创建加号循环内累加拼接差平方级复制优线性追加StringBuilder拼接数量在编译期已知且固定优良加号拼接数量运行时才确定差优StringBuilder多线程环境拼接需额外同步需用线程安全版本视情况3. StringBuilder 的内部机制与正确用法3.1 可变字符缓冲区的工作原理StringBuilder 的核心思路和不可变字符串正好相反它内部维护一个可变的字符数组append 操作就是把新内容写进这个数组的末尾同时更新一个表示当前长度的计数器。只要数组容量够append 就只是简单的数组写入不涉及新对象分配也不涉及整体复制。只有当写入的内容超出了当前数组容量时才会触发扩容分配一个更大的新数组把旧内容复制过去然后继续写入。扩容通常按一定倍数增长比如翻倍这样随着内容增长扩容的次数是对数级别的而不是每次 append 都扩容。总的字符复制量因此降到线性级别和最终字符串的长度成正比。这就是 StringBuilder 在循环拼接场景下碾压加号的根本原因它把 N 次拼接的总复制量从平方级降到了线性级同时把 N 次对象分配降到了少数几次主要是扩容时的数组分配。3.2 预设容量一个容易被忽略的优化点StringBuilder 有个构造函数可以指定初始容量。很多人写代码时习惯用无参构造让它自己扩容。这在内容不长时没问题但如果能提前估算出最终字符串的大致长度指定容量可以进一步减少扩容次数。// 不预设容量依赖自动扩容 StringBuilder sb new StringBuilder(); // 预设容量减少扩容 StringBuilder sb new StringBuilder(estimatedLength);估算容量不需要非常精确宁可稍微大一点。比如你要拼接一万条记录每条平均五十个字符那初始容量给个六十万左右就比较合适。容量给大了浪费一点内存但比起反复扩容复制的开销这点浪费完全值得。我在那个导出模块的优化里除了换成 StringBuilder还根据记录数和平均字段长度预设了容量最终耗时比单纯换 StringBuilder 又降了一截。这个细节很多人会忽略但在数据量大的时候效果明显。3.3 append 链式调用与类型处理StringBuilder 的 append 方法返回自身所以可以链式调用写起来很紧凑StringBuilder sb new StringBuilder(1024); sb.append(用户: ).append(userName) .append(, 年龄: ).append(age) .append(, 城市: ).append(city);append 对不同类型的参数有重载版本基本类型会直接转换成字符写入避免了先装箱再转字符串的额外开销。这一点比用加号拼接时可能发生的隐式转换要高效。比如拼接一个整数加号会先把它转成字符串对象再拼接而 append 可以直接把数字的字符表示写进缓冲区。需要注意的是append 传入对象时如果对象为 null它会写入 null 这个字符串而不是抛异常。这个行为有时候是便利有时候是坑取决于你的业务是否需要区分空值和字符串 null。如果需要区分拼接前要自己做判空处理。3.4 线程安全的取舍StringBuilder 不是线程安全的。如果多个线程同时往同一个 StringBuilder 里 append可能出现内容错乱甚至数组越界。如果你的拼接操作确实跨线程有两个选择一是用线程安全的 StringBuffer它的方法加了同步二是每个线程用自己的 StringBuilder最后再合并。StringBuffer 因为每个方法都要加锁单线程下比 StringBuilder 慢一些。所以除非真的需要跨线程共享否则优先用 StringBuilder。大多数拼接场景其实都是单线程的局部操作用 StringBuilder 就够了。4. 选型决策什么情况用什么别再凭感觉4.1 按数据规模划分的实用标准选型最直接的依据是数据规模。我一般用这样的经验标准来判断拼接的片段数量在个位数且是单个表达式内完成直接用加号代码清晰。片段数量在几十个以内且不在循环里加号通常也能接受但如果有性能敏感要求可以换 StringBuilder。片段数量上百或者出现在循环里无条件用 StringBuilder。拼接结果可能达到几万字符以上用 StringBuilder 并预设容量。这个标准不是绝对的但能覆盖绝大多数日常场景。核心判断依据是拼接次数是否随数据量增长以及是否在循环里。只要命中这两点之一就该警惕。4.2 可读性与性能的平衡有人担心用 StringBuilder 会让代码变啰嗦影响可读性。确实一个简单的a b c改成 StringBuilder 要写好几行。但我的看法是在性能敏感的地方可读性要让位于正确性在性能不敏感的地方可读性优先。具体来说如果这段拼接在热点路径上比如被高频调用的方法、处理大批量数据那就老老实实用 StringBuilder哪怕代码长一点。如果只是偶尔执行一次的配置组装、日志前缀拼接用加号完全没问题没必要为了理论上的性能牺牲可读性。判断是否在热点路径可以借助性能分析工具看这段代码在整体耗时中的占比。占比高就优化占比低就别折腾。过早优化是万恶之源但明知有性能陷阱还往里跳那就是另一回事了。4.3 特殊场景的处理思路有些场景比较特殊需要单独考虑。比如拼接 SQL 语句除了性能还要考虑注入风险这时候应该用参数化查询而不是字符串拼接这是安全层面的要求优先级高于性能。再比如拼接大量文本做导出除了 StringBuilder还可以考虑流式写入边拼边写避免在内存里保留完整的大字符串。还有一种情况是拼接结果要作为缓存键或者哈希键这种场景下字符串长度通常可控用加号或 StringBuilder 差别不大重点应该放在键的稳定性和唯一性上。场景类型首要考虑推荐方案高频调用的日志拼接性能StringBuilder 预设容量一次性配置组装可读性加号大批量数据导出内存与性能StringBuilder 或流式写入SQL 语句构建安全参数化查询缓存键生成稳定性加号或 StringBuilder 均可5. 实测对比与常见误区澄清5.1 一组可复现的对比测试为了让大家有直观感受我做过一组简单的对比测试。测试内容是拼接十万条记录每条记录包含三个字段分别用加号和 StringBuilder 实现统计耗时和 GC 次数。测试环境是常见的开发机配置结果如下实现方式平均耗时新生代 GC 次数循环内加号约 8.5 秒数百次StringBuilder 无预设容量约 0.4 秒个位数StringBuilder 预设容量约 0.3 秒个位数这个结果和理论分析吻合加号的耗时随数据量平方增长而 StringBuilder 接近线性。预设容量又比自动扩容略快一点。需要说明的是具体数值会随环境变化但数量级的差距是稳定的。测试代码本身很简单核心就是两个方法一个用加号循环累加一个用 StringBuilder 循环 append然后用相同的输入数据跑记录时间和 GC 情况。如果你想自己验证可以照着这个思路写一个注意要跑足够大的数据量才能看出差距数据量太小的话两者都在毫秒级看不出区别。5.2 几个流传很广的错误说法关于字符串拼接有几个说法流传很广但经不起推敲。第一个说法是加号在任何情况下都比 StringBuilder 慢。这是错的。单个表达式内的少量拼接编译器优化后加号并不慢甚至因为代码简洁而更优。盲目把所有加号都改成 StringBuilder只会让代码变啰嗦收益却为零。第二个说法是StringBuilder 一定比加号快。这也不对。如果只拼接两三个字符串创建 StringBuilder 对象本身也有开销这时候加号反而更直接。StringBuilder 的优势要在拼接次数多、数据量大时才体现出来。第三个说法是用了 StringBuilder 就不用管性能了。实际上如果不预设容量、如果拼接逻辑本身有问题比如在循环里反复 toStringStringBuilder 也可能表现不佳。工具用对了才有效用错了照样出问题。5.3 容易被忽视的隐性拼接有些拼接是隐性的不容易被发现。比如在循环里用加号拼接日志消息、在循环里用加号构建异常信息、在循环里用加号累加查询条件。这些操作表面上不是字符串拼接但底层执行的就是拼接同样有性能问题。还有一种隐性拼接发生在字符串格式化里。某些格式化方法内部也是通过拼接实现的如果在循环里调用效果和直接用加号差不多。所以排查性能问题时不能只看显式的加号还要留意这些包装过的拼接操作。注意在循环里拼接日志是最常见的性能陷阱之一。很多日志框架支持占位符写法只有在日志级别真正需要输出时才做拼接能有效避免无谓的开销。如果你的日志代码在循环里用加号拼消息建议改成占位符形式。6. 从拼接问题延伸出的编码习惯6.1 对看起来简单的操作保持警惕字符串拼接的案例给我最大的启发是越是看起来简单的操作越容易藏着性能陷阱。因为简单所以人们不设防因为不设防所以问题积累到爆发时才被发现。类似的还有集合的频繁扩容、正则表达式的重复编译、数据库连接的频繁创建销毁等等。养成一个习惯当你写下一段会被反复执行的代码时停下来想一想这段代码每次执行会产生多少对象、做多少复制、有没有可以复用的东西。这个思考过程不需要很精确但能帮你避开大部分明显的坑。6.2 用工具验证而不是靠直觉性能问题最忌讳靠直觉判断。我觉得这段代码慢它可能并不慢我觉得这段代码没问题它可能是瓶颈。正确的做法是用工具测量性能分析工具能告诉你时间花在哪里GC 日志能告诉你内存分配情况基准测试能给你可对比的数据。我在优化那个导出模块之前其实也隐约觉得拼接可能有问题但没有数据支撑不敢贸然改动。直到抓了 GC 日志、跑了对比测试才确认问题所在改动也就有了底气。数据驱动的优化比拍脑袋靠谱得多。6.3 把经验沉淀成团队规范个人的经验如果不沉淀下来很容易随着人员流动而丢失。字符串拼接这种问题完全可以在团队层面形成规范比如约定循环内禁止用加号拼接、批量文本处理必须用 StringBuilder 并预设容量、代码评审时重点关注循环内的字符串操作等等。规范不需要很复杂几条关键的红线就够了。关键是让每个人都理解这些规范背后的原因而不是机械遵守。理解了原因遇到规范没覆盖的新情况也能自己做出正确判断。7. 不同技术栈下的对应方案7.1 主流语言里的对应工具字符串拼接不是某一种语言独有的问题几乎所有语言都有对应的解决方案。Java 里有 StringBuilder 和 StringBufferC# 里有 StringBuilderPython 里推荐用 join 方法拼接列表JavaScript 里可以用数组的 join 或者模板字符串配合数组收集Go 里有 strings.Builder。虽然工具名字不同但核心思路是一致的用一个可变的缓冲区来累积内容避免每次拼接都创建新对象。理解了 Java 里 StringBuilder 的原理迁移到其他语言时只要找到对应的可变缓冲区工具思路是相通的。7.2 选择工具时的通用原则不管用什么语言选择拼接方式时可以遵循几个通用原则。第一看拼接次数是否随数据量增长是则用缓冲区工具。第二看是否有现成的批量拼接方法比如 Python 的 join它比手动循环拼接更高效也更简洁。第三看是否需要线程安全需要则选带同步的版本。第四能预估长度就预估减少扩容。这些原则不依赖具体语言是跨技术栈通用的。掌握了原则换语言时也能快速上手对应的工具。7.3 框架和库提供的封装很多框架和库已经封装好了高效的拼接逻辑用的时候直接调用即可不必自己造轮子。比如日志框架的占位符、模板引擎的渲染方法、序列化库的输出接口它们内部通常都做了优化。使用这些封装既能保证性能又能让代码更简洁。但要注意封装不是万能的。如果封装的接口本身设计得不好比如每次调用都创建新对象那在循环里用照样有问题。所以使用任何封装时都要了解它的大致实现思路知道它在什么情况下高效、什么情况下可能成为瓶颈。字符串拼接这件事说到底是一个关于理解底层的问题。加号和 StringBuilder 只是表象真正重要的是理解不可变对象、内存分配、复制开销这些底层机制。理解了这些你不仅能正确处理字符串拼接还能举一反三识别出其他类似的性能陷阱。我在实际项目里踩过的坑、做过的优化最终都指向同一个结论对基础知识的理解深度决定了你排查问题的速度和写出高质量代码的能力。
字符串拼接这件事几乎每个写代码的人都觉得自己会。不就是把两段文字接在一起吗加号一敲就完事了。但我见过太多项目在日志拼装、SQL 组装、大批量文本导出这些场景里因为随手用了加号导致接口响应从几十毫秒涨到几秒CPU 飙高GC 频繁最后排查半天才发现问题出在一行看起来人畜无害的str str item上。这篇内容就围绕这个看似基础、实则暗藏玄机的话题展开把加号和 StringBuilder.append 这两种方式从底层原理、编译期优化、运行时表现到实际选型标准掰开揉碎讲清楚。不管你是刚入行的新手还是写了几年业务代码的老手只要你的项目里存在循环拼接、批量文本处理、动态 SQL 构建这类操作这篇内容都值得你花时间看完。1. 从一段线上告警说起加号到底慢在哪1.1 一个真实的性能劣化场景之前参与过一个数据导出模块的优化功能本身不复杂从数据库分批读取记录把每条记录的若干字段拼成一行文本最后输出成一个大的文本文件。最初的实现非常直白用一个字符串变量不断累加代码大概长这样String result ; for (Record record : recordList) { result result record.getFieldA() , record.getFieldB() \n; }单次导出几百条记录时一切正常响应时间在可接受范围内。但当数据量涨到几万条时接口耗时直接突破十秒监控上能看到明显的 GC 次数激增。当时第一反应是数据库查询慢排查后发现查询只占了几百毫秒真正的耗时全在循环拼接这一段。把加号换成 StringBuilder 之后同样的数据量耗时降到了几百毫秒级别差距接近二十倍。这个案例不是个例。字符串拼接的性能问题有个特点数据量小的时候完全看不出来一旦量级上来劣化是指数级的而不是线性的。很多人因此产生误判觉得我平时用加号也没出过问题直到某天数据量增长问题才突然爆发。1.2 不可变字符串带来的连锁反应要理解加号为什么慢得先回到字符串这个类型的设计本身。在主流语言里字符串通常被设计成不可变对象也就是说一个字符串实例一旦创建它内部承载的字符序列就不能被修改。这个设计带来很多好处比如线程安全、可以安全地作为哈希表的键、便于缓存哈希值等等。但代价是任何看起来像修改字符串的操作本质上都是创建了一个全新的字符串对象。所以当你写下result result record.getFieldA()时运行时实际发生的事情是先读取 result 原有的全部字符再读取新字段的字符在内存里开辟一块新空间把两部分内容复制进去生成一个新的字符串对象最后把这个新对象的引用赋给 result。原来那个 result 对象就此变成垃圾等待被回收。单看一次操作这点开销微不足道。但放到循环里问题就被放大了。假设循环执行 N 次第 i 次拼接时需要复制的字符数量大致正比于前 i-1 次累积的总长度。把所有轮次加起来总的复制量大致是 N 的平方级别。这就是为什么数据量翻倍耗时可能变成四倍甚至更多。1.3 内存分配的隐性成本除了字符复制还有内存分配的成本。每一次拼接都意味着一次新的对象分配。在循环里这意味着短时间内产生大量生命周期极短的临时字符串对象。这些对象会迅速填满新生代内存区域触发频繁的垃圾回收。垃圾回收本身不是免费的。即便是针对新生代的轻量级回收也需要暂停应用线程、扫描存活对象、复制整理内存。当回收频率高到一定程度应用的吞吐量就会明显下降。更麻烦的是如果这些临时对象中有部分因为某些原因存活时间稍长被晋升到了老年代那后续的回收成本会更高甚至可能触发全局停顿。我在排查那个导出模块时特意抓取了 GC 日志能看到在拼接阶段新生代回收几乎每隔一两秒就触发一次而正常业务逻辑下这个间隔是几十秒。这就是典型的对象分配速率过高导致的 GC 压力。提示判断字符串拼接是否是性能瓶颈一个简单的方法是看 GC 日志里新生代回收的频率以及火焰图里字符串相关方法如数组复制、对象分配的占比。如果这两项都偏高基本可以锁定问题。2. 编译器的糖衣加号并非总是那么慢2.1 编译期优化到底做了什么看到这里可能有人会问既然加号这么慢为什么很多资料又说简单的字符串拼接用加号就行这里的关键在于编译器会对加号做一定程度的优化把某些拼接操作自动转换成类似 StringBuilder 的形式。以 Java 为例对于单个表达式里的连续拼接比如String s a b c d;编译器在编译期就会把它改写成创建一个 StringBuilder或类似的辅助对象依次 append 各个部分最后调用 toString。这种情况下加号的实际执行效率和手写 StringBuilder 差别不大因为编译器已经帮你做了转换。这个优化的意义在于它让代码保持了可读性同时避免了简单场景下的性能损失。所以如果你只是在一个表达式里拼接几个固定的变量用加号完全没问题不必为了性能刻意改成 StringBuilder那样反而牺牲了可读性。2.2 循环里的加号为什么优化不掉问题出在循环里。编译器能优化的是单个表达式内部的连续拼接它没法跨循环迭代去复用辅助对象。也就是说下面这段代码String result ; for (int i 0; i n; i) { result result data[i]; }编译器会把它理解成每次循环迭代里都有一个独立的拼接表达式result data[i]。它可以在这一次迭代内部创建一个辅助对象来完成拼接但下一次迭代又会创建一个新的辅助对象。更关键的是每次迭代结束时都要调用 toString 生成最终的字符串赋给 result这个 toString 又是一次完整的字符复制。所以循环里的加号等价于每一轮都新建一个 StringBuilder、append 两个部分、toString 一次、丢弃。累积下来依然是平方级别的复制量和大量的对象分配。编译器帮不了你因为跨迭代的对象复用超出了它的优化范围。2.3 不同语言和版本的差异需要说明的是不同语言、甚至同一语言的不同版本对加号的优化策略并不相同。有些语言的编译器或运行时更激进能识别出循环模式并做优化有些则相对保守。较新的 Java 版本引入了更高效的字符串拼接机制在特定场景下表现优于传统的 StringBuilder但这通常针对的是固定参数个数的拼接循环累加依然需要开发者自己处理。我的建议是不要依赖对编译器优化的猜测来写代码。与其纠结这个版本会不会帮我优化不如在明确知道是循环拼接的场景下直接使用 StringBuilder把控制权握在自己手里。这样无论编译器怎么变代码的性能都是可预期的。场景加号表现StringBuilder 表现推荐选择单个表达式拼接少量变量优编译器优化良需手动创建加号循环内累加拼接差平方级复制优线性追加StringBuilder拼接数量在编译期已知且固定优良加号拼接数量运行时才确定差优StringBuilder多线程环境拼接需额外同步需用线程安全版本视情况3. StringBuilder 的内部机制与正确用法3.1 可变字符缓冲区的工作原理StringBuilder 的核心思路和不可变字符串正好相反它内部维护一个可变的字符数组append 操作就是把新内容写进这个数组的末尾同时更新一个表示当前长度的计数器。只要数组容量够append 就只是简单的数组写入不涉及新对象分配也不涉及整体复制。只有当写入的内容超出了当前数组容量时才会触发扩容分配一个更大的新数组把旧内容复制过去然后继续写入。扩容通常按一定倍数增长比如翻倍这样随着内容增长扩容的次数是对数级别的而不是每次 append 都扩容。总的字符复制量因此降到线性级别和最终字符串的长度成正比。这就是 StringBuilder 在循环拼接场景下碾压加号的根本原因它把 N 次拼接的总复制量从平方级降到了线性级同时把 N 次对象分配降到了少数几次主要是扩容时的数组分配。3.2 预设容量一个容易被忽略的优化点StringBuilder 有个构造函数可以指定初始容量。很多人写代码时习惯用无参构造让它自己扩容。这在内容不长时没问题但如果能提前估算出最终字符串的大致长度指定容量可以进一步减少扩容次数。// 不预设容量依赖自动扩容 StringBuilder sb new StringBuilder(); // 预设容量减少扩容 StringBuilder sb new StringBuilder(estimatedLength);估算容量不需要非常精确宁可稍微大一点。比如你要拼接一万条记录每条平均五十个字符那初始容量给个六十万左右就比较合适。容量给大了浪费一点内存但比起反复扩容复制的开销这点浪费完全值得。我在那个导出模块的优化里除了换成 StringBuilder还根据记录数和平均字段长度预设了容量最终耗时比单纯换 StringBuilder 又降了一截。这个细节很多人会忽略但在数据量大的时候效果明显。3.3 append 链式调用与类型处理StringBuilder 的 append 方法返回自身所以可以链式调用写起来很紧凑StringBuilder sb new StringBuilder(1024); sb.append(用户: ).append(userName) .append(, 年龄: ).append(age) .append(, 城市: ).append(city);append 对不同类型的参数有重载版本基本类型会直接转换成字符写入避免了先装箱再转字符串的额外开销。这一点比用加号拼接时可能发生的隐式转换要高效。比如拼接一个整数加号会先把它转成字符串对象再拼接而 append 可以直接把数字的字符表示写进缓冲区。需要注意的是append 传入对象时如果对象为 null它会写入 null 这个字符串而不是抛异常。这个行为有时候是便利有时候是坑取决于你的业务是否需要区分空值和字符串 null。如果需要区分拼接前要自己做判空处理。3.4 线程安全的取舍StringBuilder 不是线程安全的。如果多个线程同时往同一个 StringBuilder 里 append可能出现内容错乱甚至数组越界。如果你的拼接操作确实跨线程有两个选择一是用线程安全的 StringBuffer它的方法加了同步二是每个线程用自己的 StringBuilder最后再合并。StringBuffer 因为每个方法都要加锁单线程下比 StringBuilder 慢一些。所以除非真的需要跨线程共享否则优先用 StringBuilder。大多数拼接场景其实都是单线程的局部操作用 StringBuilder 就够了。4. 选型决策什么情况用什么别再凭感觉4.1 按数据规模划分的实用标准选型最直接的依据是数据规模。我一般用这样的经验标准来判断拼接的片段数量在个位数且是单个表达式内完成直接用加号代码清晰。片段数量在几十个以内且不在循环里加号通常也能接受但如果有性能敏感要求可以换 StringBuilder。片段数量上百或者出现在循环里无条件用 StringBuilder。拼接结果可能达到几万字符以上用 StringBuilder 并预设容量。这个标准不是绝对的但能覆盖绝大多数日常场景。核心判断依据是拼接次数是否随数据量增长以及是否在循环里。只要命中这两点之一就该警惕。4.2 可读性与性能的平衡有人担心用 StringBuilder 会让代码变啰嗦影响可读性。确实一个简单的a b c改成 StringBuilder 要写好几行。但我的看法是在性能敏感的地方可读性要让位于正确性在性能不敏感的地方可读性优先。具体来说如果这段拼接在热点路径上比如被高频调用的方法、处理大批量数据那就老老实实用 StringBuilder哪怕代码长一点。如果只是偶尔执行一次的配置组装、日志前缀拼接用加号完全没问题没必要为了理论上的性能牺牲可读性。判断是否在热点路径可以借助性能分析工具看这段代码在整体耗时中的占比。占比高就优化占比低就别折腾。过早优化是万恶之源但明知有性能陷阱还往里跳那就是另一回事了。4.3 特殊场景的处理思路有些场景比较特殊需要单独考虑。比如拼接 SQL 语句除了性能还要考虑注入风险这时候应该用参数化查询而不是字符串拼接这是安全层面的要求优先级高于性能。再比如拼接大量文本做导出除了 StringBuilder还可以考虑流式写入边拼边写避免在内存里保留完整的大字符串。还有一种情况是拼接结果要作为缓存键或者哈希键这种场景下字符串长度通常可控用加号或 StringBuilder 差别不大重点应该放在键的稳定性和唯一性上。场景类型首要考虑推荐方案高频调用的日志拼接性能StringBuilder 预设容量一次性配置组装可读性加号大批量数据导出内存与性能StringBuilder 或流式写入SQL 语句构建安全参数化查询缓存键生成稳定性加号或 StringBuilder 均可5. 实测对比与常见误区澄清5.1 一组可复现的对比测试为了让大家有直观感受我做过一组简单的对比测试。测试内容是拼接十万条记录每条记录包含三个字段分别用加号和 StringBuilder 实现统计耗时和 GC 次数。测试环境是常见的开发机配置结果如下实现方式平均耗时新生代 GC 次数循环内加号约 8.5 秒数百次StringBuilder 无预设容量约 0.4 秒个位数StringBuilder 预设容量约 0.3 秒个位数这个结果和理论分析吻合加号的耗时随数据量平方增长而 StringBuilder 接近线性。预设容量又比自动扩容略快一点。需要说明的是具体数值会随环境变化但数量级的差距是稳定的。测试代码本身很简单核心就是两个方法一个用加号循环累加一个用 StringBuilder 循环 append然后用相同的输入数据跑记录时间和 GC 情况。如果你想自己验证可以照着这个思路写一个注意要跑足够大的数据量才能看出差距数据量太小的话两者都在毫秒级看不出区别。5.2 几个流传很广的错误说法关于字符串拼接有几个说法流传很广但经不起推敲。第一个说法是加号在任何情况下都比 StringBuilder 慢。这是错的。单个表达式内的少量拼接编译器优化后加号并不慢甚至因为代码简洁而更优。盲目把所有加号都改成 StringBuilder只会让代码变啰嗦收益却为零。第二个说法是StringBuilder 一定比加号快。这也不对。如果只拼接两三个字符串创建 StringBuilder 对象本身也有开销这时候加号反而更直接。StringBuilder 的优势要在拼接次数多、数据量大时才体现出来。第三个说法是用了 StringBuilder 就不用管性能了。实际上如果不预设容量、如果拼接逻辑本身有问题比如在循环里反复 toStringStringBuilder 也可能表现不佳。工具用对了才有效用错了照样出问题。5.3 容易被忽视的隐性拼接有些拼接是隐性的不容易被发现。比如在循环里用加号拼接日志消息、在循环里用加号构建异常信息、在循环里用加号累加查询条件。这些操作表面上不是字符串拼接但底层执行的就是拼接同样有性能问题。还有一种隐性拼接发生在字符串格式化里。某些格式化方法内部也是通过拼接实现的如果在循环里调用效果和直接用加号差不多。所以排查性能问题时不能只看显式的加号还要留意这些包装过的拼接操作。注意在循环里拼接日志是最常见的性能陷阱之一。很多日志框架支持占位符写法只有在日志级别真正需要输出时才做拼接能有效避免无谓的开销。如果你的日志代码在循环里用加号拼消息建议改成占位符形式。6. 从拼接问题延伸出的编码习惯6.1 对看起来简单的操作保持警惕字符串拼接的案例给我最大的启发是越是看起来简单的操作越容易藏着性能陷阱。因为简单所以人们不设防因为不设防所以问题积累到爆发时才被发现。类似的还有集合的频繁扩容、正则表达式的重复编译、数据库连接的频繁创建销毁等等。养成一个习惯当你写下一段会被反复执行的代码时停下来想一想这段代码每次执行会产生多少对象、做多少复制、有没有可以复用的东西。这个思考过程不需要很精确但能帮你避开大部分明显的坑。6.2 用工具验证而不是靠直觉性能问题最忌讳靠直觉判断。我觉得这段代码慢它可能并不慢我觉得这段代码没问题它可能是瓶颈。正确的做法是用工具测量性能分析工具能告诉你时间花在哪里GC 日志能告诉你内存分配情况基准测试能给你可对比的数据。我在优化那个导出模块之前其实也隐约觉得拼接可能有问题但没有数据支撑不敢贸然改动。直到抓了 GC 日志、跑了对比测试才确认问题所在改动也就有了底气。数据驱动的优化比拍脑袋靠谱得多。6.3 把经验沉淀成团队规范个人的经验如果不沉淀下来很容易随着人员流动而丢失。字符串拼接这种问题完全可以在团队层面形成规范比如约定循环内禁止用加号拼接、批量文本处理必须用 StringBuilder 并预设容量、代码评审时重点关注循环内的字符串操作等等。规范不需要很复杂几条关键的红线就够了。关键是让每个人都理解这些规范背后的原因而不是机械遵守。理解了原因遇到规范没覆盖的新情况也能自己做出正确判断。7. 不同技术栈下的对应方案7.1 主流语言里的对应工具字符串拼接不是某一种语言独有的问题几乎所有语言都有对应的解决方案。Java 里有 StringBuilder 和 StringBufferC# 里有 StringBuilderPython 里推荐用 join 方法拼接列表JavaScript 里可以用数组的 join 或者模板字符串配合数组收集Go 里有 strings.Builder。虽然工具名字不同但核心思路是一致的用一个可变的缓冲区来累积内容避免每次拼接都创建新对象。理解了 Java 里 StringBuilder 的原理迁移到其他语言时只要找到对应的可变缓冲区工具思路是相通的。7.2 选择工具时的通用原则不管用什么语言选择拼接方式时可以遵循几个通用原则。第一看拼接次数是否随数据量增长是则用缓冲区工具。第二看是否有现成的批量拼接方法比如 Python 的 join它比手动循环拼接更高效也更简洁。第三看是否需要线程安全需要则选带同步的版本。第四能预估长度就预估减少扩容。这些原则不依赖具体语言是跨技术栈通用的。掌握了原则换语言时也能快速上手对应的工具。7.3 框架和库提供的封装很多框架和库已经封装好了高效的拼接逻辑用的时候直接调用即可不必自己造轮子。比如日志框架的占位符、模板引擎的渲染方法、序列化库的输出接口它们内部通常都做了优化。使用这些封装既能保证性能又能让代码更简洁。但要注意封装不是万能的。如果封装的接口本身设计得不好比如每次调用都创建新对象那在循环里用照样有问题。所以使用任何封装时都要了解它的大致实现思路知道它在什么情况下高效、什么情况下可能成为瓶颈。字符串拼接这件事说到底是一个关于理解底层的问题。加号和 StringBuilder 只是表象真正重要的是理解不可变对象、内存分配、复制开销这些底层机制。理解了这些你不仅能正确处理字符串拼接还能举一反三识别出其他类似的性能陷阱。我在实际项目里踩过的坑、做过的优化最终都指向同一个结论对基础知识的理解深度决定了你排查问题的速度和写出高质量代码的能力。
