Java字符串拼接方法对比：+、concat与StringBuilder

Java字符串拼接看似简单，实则暗藏性能陷阱：编译期常量用“+”零开销，但一旦涉及变量、循环或动态内容，盲目使用“+”或concat会引发大量临时对象创建、O(n²)时间复杂度和频繁GC；StringBuilder并非锦上添花的优化技巧，而是循环拼接、模板构建、大容量预估等场景下不可替代的刚需工具——选对方法，不仅代码更健壮，性能还能提升数十倍。

字符串拼接用 + 会生成多少临时对象？

Java 中用 + 拼接字符串，编译器会自动转成 StringBuilder（JDK 5+），但仅限于**编译期可确定的字符串常量表达式**。一旦涉及变量、循环或方法调用，就容易在运行时反复创建新 StringBuilder 实例，导致额外对象开销。

• 静态拼接："a" + "b" + "c" → 编译期直接优化为 "abc"，零对象
• 含变量拼接："prefix" + str + 123 → 每次执行都 new 一个 StringBuilder，再 toString()，产生至少 1 个新 String 对象
• 循环内写 result += s → 每轮都新建 StringBuilder + String，时间复杂度 O(n²)

String.concat() 和 + 的行为差异在哪？

String.concat() 是纯函数式操作：只接受一个 String 参数，内部用 Arrays.copyOf 拷贝字节数组，不复用缓冲区。它比 + 更“老实”，但也更“死板”——不支持多参数、不处理 null、不自动装箱。

• 遇到 null 直接抛 NullPointerException，而 + 会转成字符串 "null"
• "a".concat("b").concat("c") 看似链式，实则每步都生成新 String，无缓冲复用
• 参数必须是 String 类型，"a".concat(123) 编译失败，得先 String.valueOf(123)

什么时候必须用 StringBuilder？

三种典型场景下，StringBuilder 不是“推荐”，而是“绕不开”：

• 循环拼接（尤其是 for 或 while 中累积字符串）
• 需要复用同一缓冲区多次构建不同结果（比如模板填充、日志组装）
• 已知最终长度，可提前用 new StringBuilder(capacity) 避免数组扩容（例如拼接 100 个固定长字符串，预估总长后设初始容量）

示例：

StringBuilder sb = new StringBuilder(512); // 预分配避免扩容
for (String s : list) {
    sb.append(s).append(",");
}
String result = sb.toString(); // 只在最后调用一次 toString()

性能差距到底有多大？

在 10k 次拼接测试中（每个片段平均 20 字符）：

• += 循环：约 8–12ms（JDK 17，HotSpot），且 GC 压力明显
• StringBuilder 复用：稳定在 0.3–0.5ms
• String.concat() 链式调用：约 4–6ms（每次都要拷贝数组）

差距主要来自内存分配频次和数组复制次数。不过，如果只是偶尔拼两三个字符串（如日志里加个 ID），+ 完全够用，过度优化反而让代码变重。

真正容易被忽略的是：局部 StringBuilder 实例虽然快，但如果在高并发方法里频繁 new，也会触发 minor GC；更稳妥的做法是方法内声明、用完即弃，别试图缓存或复用跨调用的实例。

以上就是《Java字符串拼接方法对比：+、concat与StringBuilder》的详细内容，更多关于的资料请关注golang学习网公众号！