1. 字符串拼接的性能陷阱从一次线上事故说起我先讲个真事。去年我们系统做了一次大促压测有个订单导出接口的 TP99 直接从 80ms 飙到了 1200ms排查了半天最后定位到的元凶竟然是十几行不起眼的字符串拼接代码。那是个循环里用“”拼 JSON 字符串的逻辑数据量一上来GC 频率暴涨Old 区直接被撑爆整批线程都在等内存回收。那次事故之后我认真把字符串拼接这件事从头到尾捋了一遍发现大多数人对“用‘’还是 StringBuilder”的判断几乎全是凭感觉有人逢循环必用 StringBuilder写得又臭又长有人贪图方便全程“”等出问题了才追悔莫及还有人把 StringBuffer、String.join、字符串模板一股脑混着用根本不理解各自的适用边界。这篇博文我想把这件事掰开揉碎讲清楚底层到底发生了什么、哪些场景“”真的无所谓、哪些场景不用 StringBuilder 一定会出事、以及除了这两个还有哪些更优的姿势。目标是让你看完之后不是背结论而是真正能基于场景做出合理判断。内容对 Java 开发最直接但 Python、C# 里类似的问题我也会顺带提一嘴毕竟原理是相通的。2. 先搞清楚“”在底层到底干了什么2.1 不可变对象是根因要理解拼接的性能差异绕不开一个基础概念String 是不可变的。这在 Java 里是 final class底层的 byte 数组也是 final 的一旦创建内容就不能再改。不可变带来的好处显而易见线程安全、可以放心做字符串常量池缓存、hashCode 可以提前算好。但它也有一个非常膈应的副作用——任何看起来像“修改”的操作实际都是创建一个新对象。这就好比你在一张纸上写了一段话想追加几个字结果不能直接在纸上改而是必须重新拿一张新纸把原文一字不差地抄一遍再在后面补上新字。如果只追加一次成本还能接受如果是在循环里反复追加那就是反复誊抄整张纸每次的代价都在累积。2.2 编译器的“障眼法”很多 Java 开发者在学习阶段就被告知“‘’在编译期会被优化成 StringBuilder”。这句话说对了一半但恰恰是这一半害了很多人。先看一个典型案例String s Hello , World;这段代码的字节码确实和下面这段几乎等价String s new StringBuilder(Hello).append(, ).append(World).toString();编译器的确做了这种优化而且在编译期就能确定字面量的情况下甚至连 StringBuilder 都不用直接就是常量折叠成Hello, World。但请注意这种优化有非常严格的前提——这些拼接操作必须发生在同一个表达式内编译器才能一次性生成一个 StringBuilder 并把所有 append 串在一起。一旦拼接发生在循环里情况就完全变了。看这段String result ; for (int i 0; i 10000; i) { result result , i; }你以为编译器会聪明地把它优化成循环外用一次 StringBuilder并不会。字节码里面每次循环都会new一个 StringBuilderappend 前面已累计的内容再 append 新值然后 toString 转回 String。等于说 10000 次循环就创建了 10000 个 StringBuilder 对象加 10000 个中间 String 对象。这里直接贴一下我的实测数据JDK 8 环境下拼接 10 万次用“”耗时约 4200ms用 StringBuilder 约 8ms差距超过 500 倍。而且“”方案还产生了大约 20 万个中间对象给 GC 带来了巨大压力。2.3 循环内 vs 循环外的“”行为差异为了更直观我把同为“”写法的两种代码做了对比// 写法 A循环内拼接低效 String result ; for (int i 0; i 100000; i) { result result i; }// 写法 B循环内收集循环外拼接高效 String[] parts new String[100000]; for (int i 0; i 100000; i) { parts[i] String.valueOf(i); } String result String.join(,, parts);写法 A 的问题在于每轮循环 String 的引用指向一个新对象旧对象变成垃圾。随着 result 越来越长复制成本越来越高整体复杂度是 O(n²)n 越大越离谱。写法 B 则避开了中间 String 的反复复制先收集再一次性拼接复杂度能回到 O(n)。如果你真要在循环里用“”至少要确保编译器能一次性处理也就是拼接表达式不跨语句、不跨循环。但现实中的业务代码很少这么规整所以不能把“编译器会优化”当成万能挡箭牌。3. StringBuilder 的正确打开方式以及常见误用3.1 什么时候必须上 StringBuilder我个人的判断标准很简单满足以下任一条件就考虑用 StringBuilder拼接操作发生在循环、递归或批处理场景中次数不可控。目标字符串是动态累积的且无法提前预知最终长度。拼接内容来自多个数据源需要先处理再合并。你明确知道性能指标里有 TP99、GC 频率等约束。比如最常见的手动拼接 JSON 或日志StringBuilder sb new StringBuilder(); sb.append({\userId\:).append(userId); sb.append(,\name\:\).append(name).append(\); sb.append(,\tags\:[); for (String tag : tags) { if (sb.charAt(sb.length() - 1) ! [) { sb.append(,); } sb.append().append(tag).append(); } sb.append(]}); String json sb.toString();这种场景如果你用“”硬拼代码可读性也未必好多少但性能上绝对吃大亏。老实说现在很多场景其实不该自己拼 JSON用 Jackson、Gson 序列化更安全这是后话。3.2 初始容量别乱拍脑袋StringBuilder 有默认容量 16超出后会自动扩容。问题在于扩容是有代价的新容量大约是旧容量的两倍加二需要申请新数组、把旧数据复制过去。如果拼接目标最终长度很大中途就会发生多次扩容。举个具体例子你要拼一个 10 万字符的日志文本默认从 16 开始扩容路径大致是 16 → 34 → 70 → 142 ... 一直到 131072中间经历了大约 13 次扩容每次都要复制已有内容。这些复制操作累加起来虽然比“”的 O(n²) 好一些但完全没必要白白浪费。正确姿势是在创建时预估容量// 假设大概有 5000 条记录每条平均长度 60 StringBuilder sb new StringBuilder(5000 * 60);容量设置略大没关系的不会像数组那样越界报错只是多占一点内存。设置偏小了顶多多扩容几次。工程上我一般会再乘一个 1.1~1.3 的系数因为实际长度往往比预估要长一点一次到位能有效减少复制次数。3.3 StringBuilder 是线程不安全的这是很多初学者容易踩的坑。StringBuilder 的 append 方法没有任何同步保护多线程同时操作同一个实例轻则数据错乱重则抛 ArrayIndexOutOfBoundsException。网上很多老教程会教你用 StringBuffer说它线程安全。这话没错但你需要先想清楚你真的需要线程安全吗大部分字符串拼接场景都是线程私有的也就是一个线程自己收集数据、自己拼结果根本不涉及共享。这种情况下你用 StringBuffer纯粹是白白给每个 append 方法加锁性能白丢。我实测过JDK 8 下 StringBuffer 比 StringBuilder 慢大约 20% 到 30%。如果你的场景真的是多线程同时往同一个缓冲里写内容那也不建议直接用 StringBuffer而是应该重新设计要么每个线程维护自己的 StringBuilder最后再合并要么用并发队列收集片段最后统一拼接。保证“线程私有拼接、全局有序合并”的性能远好于一个全局锁。4. 除了“”和 StringBuilder你还有其他选择4.1 StringBuffer 的历史包袱与现状StringBuffer 是 JDK 1.0 就存在的类所有公开方法都加了 synchronized。在单线程场景里它没有任何优势纯粹是历史包袱。那它有没有不可替代的场景说实话日常业务开发里基本没有。如果是因为“担心并发问题”而选择它我更建议先搞清楚到底有没有并发问题。大多数时候答案是没有。4.2 String.join 和 Collectors.joining有固定分隔符的集合拼接其实根本不需要手动写循环加 append。Java 8 以后提供了非常清爽的姿势ListString names Arrays.asList(Alice, Bob, Charlie); String joined String.join(, , names); // 流式场景 String result users.stream() .map(User::getName) .collect(Collectors.joining(, , [, ]));这种写法有两个好处一是代码意图一目了然不会写出一长串 append二是 JDK 底层实现经过了充分调优大多数情况下性能不输手写 StringBuilder。我见过太多人明明只是做一个“把数组元素用逗号拼起来”的需求结果硬是写了一个循环加 StringBuilder 的十行代码。不是说性能不行而是这份代码的可读性和维护性都值得商榷。能用 join 表达的场景优先用 join。4.3 模板字符串与消息格式化Java 在较新的特性里对字符串模板做了很多探索虽然没有像 Python 的 f-string 那样直接落地但日常用 String.format 也能解决很多场景String msg String.format(用户 %s 在 %s 完成了支付金额 %.2f 元, userName, time, amount);这种写法清晰度最高适合固定格式的少量拼接。性能上String.format 因为有格式化解析的开销比直接拼接慢一些但它省去的代码量和出错概率是实打实的。如果这段代码不是热点路径我毫不犹豫选 format。需要特别说的是 Python 的情况f-string是 Python 3.6 的语法糖内部会调用__format__协议性能上好于%格式化和.format()。但要注意Python 里用拼接大量字符串同样存在 O(n²) 问题正确姿势是用.join(list)原理和 Java 的 StringBuilder 异曲同工。C# 那边也有类似的规律少量拼接直接用$字符串插值编译器会优化成 string.Concat 或 StringBuilder循环里则建议用StringBuilder或者string.Join。每个语言都存在同样的问题只是语法形式不同而已。4.4 我在实际项目里的选型参考给一个我常用的快速判断清单按优先级从高到低能用一句话说清的固定格式 - String.format / 模板表达式集合转分隔符字符串 - String.join / Collectors.joining循环累加、动态构建 - StringBuilder预分配容量需要线程安全的共享缓冲 - 重新设计架构而不是用 StringBuffer极简场景、代码行数少且不在热点路径 - 用“”无所谓这条清单我贴在工位上了每次 code review 我都对照着说基本能覆盖 90% 的争论。5. 不同语言的字符串拼接策略横向对比5.1 Java、C#、Python、Go 的真实差异很多人以为“用 StringBuilder 总没错”但这不是一个放之四海而皆准的结论。我花时间把不同语言的底层实现做了对比结论差别很大。Java 的“”在循环外会被编译器优化成 StringBuilder循环内不行。C# 的$插值在底层会选择 string.Concat 或 DefaultInterpolatedStringHandler小规模场景下甚至比 StringBuilder 更快。Python 的“”在小规模下没问题但在大规模循环里会引发严重的 reallocation 问题Python 官方推荐的 join 本质上也类似 StringBuilder 的思想。Go 语言里最常用的拼接方式反而是strings.Builder或fmt.Sprintf它的在循环里也慢但 Go 的编译器优化相对保守所以更依赖开发者主动选对工具。看一张对比表更清楚语言小规模拼接推荐循环内热路径底层原理Java“” 或 formatStringBuilder“”编译期转换为 StringBuilder循环内会反复创建C#$插值StringBuilder插值可编译为高效 handler循环内需手动 BuilderPythonf-string.join()f-string 语法糖高效“”累加是 O(n²)Gofmt.Sprintfstrings.Builder字符数组扩容追加sprintf 有反射开销这个表的目的是让你明白别把 Java 里“用 StringBuilder”的结论直接搬到别的语言。虽然核心理念都是“避免创建大量中间对象”但每个语言给了不同的便捷工具选型时应该先用语言原生的推荐方案。5.2 语言自带工具的底层演进以 C# 为例.NET 6 之后编译器对$做了非常强的优化。如果你写string s $Hello {name}, you are {age} years old;编译器会把它编译成DefaultInterpolatedStringHandler的调用本质上是 struct 类型的 builder可以复用 buffer而且不产生额外对象分配。这种优化力度已经让“非循环场景下用不用 StringBuilder”的争议变得没有意义。Java 这边其实也在演进。JDK 9 之后引入了 invokedynamic 做字符串拼接允许运行时选择最优的拼接策略不再只是简单翻译成 new StringBuilder。但由于 String 仍然不可变循环内用“”的问题本质上没有消失只是延迟到了运行时。所以我的结论是语言在变但底层思想不变——避免反复创建不可变中间对象。理解了这一点就算未来出现新语法你也能快速判断它是否适合热路径。6. 常见问题排查与性能分析实战6.1 从一次 GC 日志定位拼接问题回到开头说的那次大促压测事故。我当时是怎么一步步定位到字符串拼接的过程可以给各位一个参考。第一步看监控面板发现 Old 区在压测开始后快速上升Full GC 频率从每小时几次飙升到每分钟几十次GC 停顿时间多的时候能有 800ms。这种大面积的大对象进老年代常见嫌疑就是字符串拼接和集合无脑扩容。第二步用 jmap dump 出堆快照用 MAT 分析发现 char[] 数组对象数量惊人占比超过 60%其中大量是被中间 String 引用但不再使用的字符串片段。第三步按对象引用树回溯找到源头类果然是在导出服务的循环里用“”拼大字符串。第四步改动前后对比验证改成 StringBuilder 后Full GC 频率直接降回原来的水平TP99 从 1200ms 回到 70ms。整个过程其实不难难的是第一反应不要只盯业务代码逻辑。JVM 性能问题的排查核心思路永远是先看 GC再看堆最后定位到代码行。6.2 手把手教你做拼接性能基准测试判断一个拼接方案到底快不快不能靠猜要做简单基准测试。但这里有个大坑JVM 有 JIT 编译有逃逸分析方法内联之后可能你的测试结果根本不能反映真实场景。我的建议是尽量用 JMHJava 官方的微基准测试框架。下面给一个可以直接跑的测试类BenchmarkMode(Mode.AverageTime) OutputTimeUnit(TimeUnit.MILLISECONDS) State(Scope.Thread) public class StringConcatBenchmark { private static final int LOOP 100000; Benchmark public String plusInLoop() { String result ; for (int i 0; i LOOP; i) { result result , i; } return result; } Benchmark public String stringBuilder() { StringBuilder sb new StringBuilder(LOOP * 6); for (int i 0; i LOOP; i) { sb.append(,).append(i); } return sb.toString(); } Benchmark public String stringJoiner() { StringJoiner sj new StringJoiner(,); for (int i 0; i LOOP; i) { sj.add(String.valueOf(i)); } return sj.toString(); } }这里有个细节StringBuilder 的初始容量我直接给到了 LOOP * 6因为每个数字加逗号约 5~6 个字符这样在整个循环过程中不会触发扩容。如果你不确定长度可以给一个偏大的值但注意不要大到引发内存浪费。JMH 跑出来的结果通常会吓你一跳循环内“”比 StringBuilder 慢一到两个数量级StringJoiner 和 StringBuilder 差距不大但可读性更好。所以我个人的建议是在需要收集元素的场景里StringJoiner 通常比手动控制逗号的 StringBuilder 更好写、更少 bug。6.3 线上环境如何快速验证拼接热点如果线上不方便用 JMH可以用 JFR 或 arthas 做采样。arthas 里比较实用的两个命令# 火焰图采样看哪个方法占用 CPU 多 profiler start profiler stop# 方法执行耗时追踪 trace com.example.OrderExportService exportOrder #cost 100我实际用的时候一般先跑 profiler 看看整体热点再用 trace 定位到具体方法。定位到疑似拼接代码后我会在代码里加一个耗时埋点日志统计拼接部分占整个方法耗时的比例。如果占比高直接改 StringBuilder 再重新发布对比指标即可。6.4 常见编造结论这些说法别再信了我常年混技术社区看过太多关于字符串拼接的“民科”结论。这里挑几个最常见的拔一拔草“Java 9 之后循环里用‘’也很快”——错。Java 9 的 invokedynamic 只是把策略选择延迟到了运行时循环内反复创建中间 String 的问题依旧存在。做过 JMH 就能看到Java 17 里循环内拼 10 万次字符串“”依然慢得离谱。“StringBuilder 一定比‘’快”——不一定。非循环、单次表达式里“”经过编译器处理和常量折叠后与 StringBuilder 的性能差距在纳秒级别而可读性差距是肉眼可见的。为这种场景写一长串 append 就是过度优化。“所有拼接都该用 StringBuffer”——错。StringBuffer 的加锁行为在线程私有的场景里纯属负担。90% 以上的拼接场景根本不会跨线程访问同一个实例。“先用字符串累加没关系JVM 会优化”——半对。JIT 确实可以做部分优化但对不可变对象的中间创建依然无法完全消除。而且就算性能没问题GC 压力也会增加。“String.format 性能很差不该用”——看场景。固定格式的小规模拼接format 的清晰度收益远大于那几微秒的代价。热点路径才需要认真计较性能。7. 实际编码时的最佳实践与代码模板7.1 循环拼接的标准模板如果你要在一个循环里拼接字符串这是我用了多年的模板基本不出错public String buildReport(ListOrder orders) { if (orders null || orders.isEmpty()) { return ; } // 预估容量每条订单约 80 字符 StringBuilder sb new StringBuilder(orders.size() * 80); for (Order order : orders) { sb.append(order.getId()) .append(|) .append(order.getCreateTime()) .append(|) .append(order.getAmount()) .append(\n); } return sb.toString(); }注意几个细节一是我用|和\n而不是|和\nchar 类型 append 不需要创建额外的单字符 String 对象虽然差别不大但积少成多。二是append(order.getId())这里如果 getId 返回 int会自动调用 append(int)不会有 String 转换开销如果返回的是 String就直接 append。三是我先判空再创建 StringBuilder避免无意义的对象分配。7.2 常用库的替代方案实际项目中如果拼接的目标是 JSON、XML 这种结构化文本我更推荐用专门的库而不是手写拼接。Jackson 的 JsonNode 构建 JSONRome 之类库构建 XML代码更安全、可读性更强也不会引入拼接 bug。如果是日志系统直接用 SLF4J 的参数化日志log.info(用户 {} 下单订单号 {}, userId, orderId);SLF4J 的底层其实也是延迟拼接如果日志级别没开启括号占位符根本不会触发 toString 和拼接操作性能远比自己先拼好整个字符串再传进去更优。很多团队没人关注这个点日志量大了之后白白浪费大量 CPU。7.3 代码审查时的检查清单我在做 code review 时遇到字符串拼接会快速过一遍以下问题拼接代码是否在循环内如果在必须用 StringBuilder 或 join。StringBuilder 是否预分配了容量如果没有确认拼接量很小或只拼一次。是否用了 StringBuffer如果是检查是否存在真实的并发共享场景。是否有更语义化的替代方案比如 String.join、Collectors.joining、日志占位符。最终字符串的用途是什么如果是 JSON/XML考虑直接用结构化序列化。拼接量有没有可能随用户输入或数据量增长有增长的话预估容量时要留余量。这六条过完基本不会出现体感明显的性能问题。8. 写代码时的最终建议字符串拼接这个问题看起来小但因为它太常用了小问题聚在一起就成了大坑。我的体会是不要定死“必须用什么”的规矩而是理解每种方式的代价和收益。日常工作里我大概有 70% 的场景直接用“”或者 String.format因为那些地方根本不在性能路径上。剩下 30% 的场景用到 StringBuilder 或 String.join这些都是循环内、动态成长、或者频率高的地方。没有银弹只有合适场景。最后分享一个小技巧在你写完一段字符串拼接代码后先停顿两秒问自己三个问题——这段代码会不会在循环里执行最终字符串大概多长有没有更语义化、更不容易写错的方式三个问题一过大概率你就能选出最合适的方案。这不是什么高深的技术但能帮你少走很多弯路。