StringBuilder是单线程大量字符串拼接的首选,因其基于可扩容char[]避免频繁GC;应避免误用StringBuffer、简单拼接或需格式化/正则的场景。
当需要在 for 循环中拼接几十次甚至上千次字符串(比如构建日志行、生成 CSV 行、组装 SQL 参数),StringBuilder 是首选。它底层用可扩容的 char[],避免了每次拼接都新建 String 对象带来的 GC 压力。
常见错误是写成这样:
String s = "";
for (int i = 0; i < 1000; i++) {
s += "item" + i; // 每次触发 new
String() + System.arraycopy()
}
换成 StringBuilder 后性能通常提升 5–10 倍(取决于 JDK 版本和长度):
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
sb.append("item").append(i);
}
String result = sb.toString();
new StringBuilder(2048) 可减少数组扩容次数toString(),它会创建新 String 对象StringBuilder 替代 String 存储长期状态——它不是不可变的,线程不安全StringBuilder.append() 返回自身,天然支持链式写法,适合逻辑分散但目标一致的拼接场景,比如 HTTP 响应体组装、模板填充、JSON 片段生成。
例如构造一个带条件字段的 JSON 片段:
StringBuilder json = new StringBuilder("{");
json.append("\"name\":\"").append(name).append("\"");
if (age > 0) {
json.append(",\"age\":").append(age);
}
if (email != null) {
json.append(",\"email\":\"").append(email).append("\"");
}
json.append("}");
+ 拼接更清晰,尤其分支多时不会产生大量临时 String
append(null) 会写入字符串 "null",不是空指针异常,需提前判空StringBuilder 当参数传入比返回拼接结果更高效(避免中间 toString())StringBuffer 和 StringBuilder API 几乎完全一致,区别只在 StringBuffer 所有 public 方法加了 synchronized。如果你明确知道拼接操作不会被多线程并发调用(比如 Servlet 的 doGet 内局部变量),就该用 StringBuilder。
实测在 JDK 17 下,单线程场景中 StringBuilder.append() 比 StringBuffer.append() 快 15%–25%,差距随调用频次增大而明显。
StringBuffer——同步开销白交,且掩盖真实并发问题StringBuffer
StringConcatFactory 已优化常量拼接,但运行时动态拼接仍绕不开 StringBuilder
以下情况用 StringBuilder 反而是过度设计:
"Hello " + name + "!" 在 JDK 9+ 会被编译器自动优化为 StringBuilder,手写反而啰嗦String.format("User %s, age %d", name, age) 更语义清晰,且底层也用了 StringBuilder,无需自己封装StringBuilder 没有 replaceAll() 或 matches(),强行用它做文本处理会写得很别扭Map key 或 switch case:必须是 String,且要求不可变性,此时 toString() 是必要步骤,但要注意别在关键路径反复创建真正容易被忽略的是:StringBuilder 的 capacity() 和 length() 不同——length() 是当前字符数,capacity() 是底层数组大小。调试时看到 capacity 远大于 length 不代表内存泄漏,只是预留空间。