为什么说Java的StringBuilder比String更适合大量字符串拼接

本文目录导读：

1. 核心原理：不可变 vs 可变
2. 性能差异的具体数据表现
3. 特殊情况：编译器的自动优化
4. 什么时候应该用 String？

这个问题的核心在于 String 的不可变性，而 StringBuilder 是可变的，在大量字符串拼接的场景下，两者在内存和性能上的表现天差地别。

以下是详细的技术对比：

核心原理：不可变 vs 可变

1. String 是不可变对象：一旦创建，其内部字符数组 final char[] 就无法修改。
   • 拼接操作的实际含义："A" + "B" + "C" 在编译或运行时，会创建一个新的 String 对象（"ABC"），而原来的 "A"、"B" 和中间过程的 "AB" 对象依然存在于内存中，等待被垃圾回收。
2. StringBuilder 是可变对象：内部维护一个可扩容的字符数组。
   • 拼接操作的实际含义：sb.append("A").append("B").append("C") 操作是直接在底层数组的末尾追加字符，如果数组容量不够，就进行扩容（通常是 旧容量 * 2 + 2），整个过程最多产生一个 StringBuilder 对象，以及最终 toString() 时的一个 String 对象。

性能差异的具体数据表现

为了直观理解,以拼接 n 个字符串为例：

时间复杂度对比

内存/对象创建对比

• String 方式：拼接 n 次，会创建约 n+1 个 String 对象（包括中间结果），这些对象占用大量内存，并给 GC（垃圾回收）带来巨大压力。
• StringBuilder 方式：通常只创建 1 个 StringBuilder 对象，加上最后调用 toString() 创建的 1 个 String 对象，总共 2 个对象。

典型场景佐证

在循环内进行拼接：

// 错误示范：在循环内使用 + 号
String s = "";
for (int i = 0; i < 1000; i++) {
    s += i; // 每次循环都创建新的 String 对象，性能极差
}
// 正确做法：使用 StringBuilder
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
    sb.append(i); // 一直在同一个对象的数组中追加
}
String result = sb.toString();

前者在实际测试中（循环1万次），执行时间可能是后者的几十倍到上百倍，且会产生大量垃圾对象。

特殊情况：编译器的自动优化

Java 编译器会对简单的、非循环内的 操作进行优化。

// 编译器会将以下代码：
String s = a + b + c;
// 自动优化为等价于：
String s = new StringBuilder().append(a).append(b).append(c).toString();

但是，这种优化有明确的局限性：

1. 循环内无效：编译器不会在循环内部自动使用 StringBuilder，它会在每次循环迭代中创建一个新的 StringBuilder，仍然效率极低，以上面的循环例子为例，编译器相当于把它变成了：

   for (int i...) {
       s = new StringBuilder().append(s).append(i).toString(); // 仍然很慢
   }

2. 初始化容量未知：编译器生成的 StringBuilder 使用的是默认容量（16），如果没有手动指定合适的初始容量，可能会导致多次扩容（数组复制），影响性能。

什么时候应该用 String？

虽然 StringBuilder 在拼接上优势明显，但 String 也有其适用场景：

• 极少量、固定的字符串拼接：如 "Hello, " + name，这种写法简洁、可读性高，性能开销可以忽略不计。
• 参数传递、配置、固定常量：String 的不可变性意味着它是线程安全的，适合作为哈希键（HashMap的Key）。
• 不需要修改的场景：如日志输出、返回固定消息。

一句话回答：String 每次拼接都会创建新对象（O(n²) 复杂度），而 StringBuilder 只在底层数组追加（O(n) 复杂度），大量拼接时，String 的方式会造成巨大的性能开销和内存浪费。