揭秘String、StringBuilder、StringBuffer拼接性能：实测数据告诉你最佳选择
1. 字符串拼接的性能迷思：为什么不能用"+"？
刚入行那会儿，我经常在代码里用"+"号拼接字符串，直到有一天线上服务突然卡死。排查发现是一个循环里拼接了几十万次字符串，直接让JVM内存爆了。那次事故让我深刻认识到，字符串拼接这件"小事"背后藏着大学问。
Java中的String对象有个重要特性：不可变性。每次用"+"拼接字符串，实际上都会在堆内存中创建新的String对象。比如下面这段代码：
String result = ""; for (int i = 0; i < 100000; i++) { result += i; // 每次循环都创建新对象 }在10万次循环中，会产生10万个临时String对象！这不仅是内存浪费，频繁的对象创建和垃圾回收还会导致明显的性能下降。实测下来，这段代码在我的笔记本上执行需要18秒多。
2. StringBuilder vs StringBuffer：线程安全的代价
为了解决String拼接的性能问题，Java提供了两个可变字符串类：StringBuilder和StringBuffer。它们底层都是可扩容的char数组，避免了频繁创建新对象。
2.1 性能对比实测
我用JMH（Java微基准测试工具）做了个严谨测试，对比三种方式拼接10万个字符串的耗时：
| 操作方式 | 平均耗时(ns/op) |
|---|---|
| String "+" | 830,811 |
| StringBuffer | 14,059 |
| StringBuilder | 12,032 |
结果很明显：StringBuilder比String快近70倍！即使是线程安全的StringBuffer，也比String快近60倍。
2.2 为什么StringBuilder更快？
StringBuffer的每个方法都用synchronized加了锁：
// StringBuffer的append方法 public synchronized StringBuffer append(String str) { toStringCache = null; super.append(str); return this; }这个锁保证了线程安全，但也带来了额外开销。而StringBuilder没有同步锁，所以在单线程环境下性能更好。实际项目中，90%的场景都是在方法内部使用，根本不需要线程安全。
3. 高手进阶：榨干StringBuilder的性能
你以为用StringBuilder就完事了？其实还有优化空间。来看这段代码：
StringBuilder sb = new StringBuilder(); for (int i = 0; i < 100000; i++) { sb.append("item").append(i).append(","); }3.1 预设容量避免扩容
StringBuilder默认初始容量是16个字符。当内容超过容量时，会自动扩容（通常是翻倍+2）。频繁扩容会导致数组拷贝，影响性能。如果我们能预估最终字符串长度：
// 预先分配足够空间 StringBuilder sb = new StringBuilder(300000);实测发现，预设容量后性能又提升了30%！因为避免了多次扩容操作。
3.2 复用StringBuilder对象
在超高并发场景下，甚至可以复用StringBuilder对象：
StringBuilder sb = new StringBuilder(300); for (int i = 0; i < 500000; i++) { sb.setLength(0); // 清空内容复用 sb.append("data").append(i); }这种方式比每次都new StringBuilder还要快3倍，但要注意线程安全问题。
4. 编译器优化的秘密：什么时候"+="更快？
有意思的是，在某些特殊情况下，直接用"+"拼接反而更快。比如：
// 编译时直接合并为常量 String result = "Hello" + "World"; // 一次性拼接多个变量 String s = s1 + s2 + s3;这是因为Java编译器会做优化，把连续的"+"操作转换为单个StringBuilder操作。但要注意几个关键点：
- 这种优化只适用于编译时可以确定的常量拼接
- 如果是循环中的拼接，编译器无法优化
- 变量太多时（超过8个），优化效果会下降
实测发现，简单的三四个变量拼接，用"+"和StringBuilder性能几乎没差别。但为了代码一致性，我建议还是统一用StringBuilder。
5. 实际项目中的选择策略
经过这些测试，我总结出以下实战经验：
- 单次拼接少量字符串：用"+"更直观，性能损失可忽略
- 循环内拼接：必须用StringBuilder，绝对不要用"+"
- 已知最终长度：创建StringBuilder时预设容量
- 超高并发场景：考虑复用StringBuilder对象
- 跨线程共享：必须用StringBuffer（但这种情况很少见）
特别提醒：JSON拼接、SQL拼接、日志拼接这些高频操作，一定要用StringBuilder。曾经有个同事在日志组件里用"+"拼接消息，直接让系统吞吐量下降了一半。
6. 常见误区与陷阱
在我做技术评审时，发现很多开发者容易踩这些坑：
误区1：在方法间传递StringBuilder
// 反例：破坏了封装性 void process(StringBuilder sb) { sb.append("data"); }StringBuilder是可变的，这样传参可能导致意外修改。更好的做法是传递String。
误区2：在类成员变量中使用StringBuilder
// 危险：非线程安全 class Service { private StringBuilder sb = new StringBuilder(); }除非做同步处理，否则应该用StringBuffer或者局部变量。
误区3：忽略编码问题
StringBuilder sb = new StringBuilder(); sb.append(new byte[]{0x41, 0x42}, 0, 2); // 可能乱码涉及字节转换时，要明确指定字符编码。
7. 性能优化的边界思考
字符串拼接的优化也要考虑可读性。比如：
// 可读性差但性能高 sb.append("姓名:").append(name).append(",年龄:").append(age); // 可读性好但性能稍差 String.format("姓名:%s,年龄:%d", name, age);在大多数业务场景中，String.format的性能损失是可以接受的。而像高频交易、算法竞赛等极端场景，才需要极致优化。
最后分享一个真实案例：我们系统有个批量导出功能，原来用String拼接要40秒，改用预分配容量的StringBuilder后降到0.5秒。这种优化带来的用户体验提升是立竿见影的。