04 | String + 背后发生了什么？别让拼接拖垮性能
摘要：循环里用
+=拼接字符串，性能差到让你怀疑人生。本文彻底讲清编译器对+的优化边界，以及StringBuilder的正确使用时机。
一、问题现象
publicclassStringConcatTest{publicstaticvoidmain(String[]args){// 方式一：用 +Strings="";longstart=System.currentTimeMillis();for(inti=0;i<100000;i++){s+=i;// ❌ 性能灾难}System.out.println("+ 耗时："+(System.currentTimeMillis()-start)+"ms");// 方式二：用 StringBuilderStringBuildersb=newStringBuilder();start=System.currentTimeMillis();for(inti=0;i<100000;i++){sb.append(i);// ✅ 性能优秀}System.out.println("StringBuilder 耗时："+(System.currentTimeMillis()-start)+"ms");}}运行结果（参考值）：
+ 耗时：约 12000ms StringBuilder 耗时：约 5ms差距超过 2000 倍！
二、踩坑现场
场景 1：循环中字符串拼接
// ❌ 错误写法：每行日志都创建 StringBuilder + toStringStringresult="";for(Orderorder:orders){result+=order.getId()+":"+order.getStatus()+",";}问题：每次+=都会创建一个新的StringBuilder对象，然后toString()生成新String，产生大量临时对象，触发频繁 GC。
场景 2：SQL 拼接
// ❌ 错误写法Stringsql="SELECT * FROM user WHERE 1=1 ";if(name!=null){sql+="AND name = '"+name+"' ";}if(age!=null){sql+="AND age = "+age+" ";}// SQL 注入风险 + 性能问题 双重踩坑三、原理解析
3.1 编译器对+的优化
Java 编译器（javac）在编译期会对字符串+进行优化：
// 你写的代码（非循环场景）Strings="Hello"+name+"!";// 编译器优化后（等价于）StringBuildersb=newStringBuilder();sb.append("Hello").append(name).append("!");Strings=sb.toString();关键结论：单个表达式内的+拼接，编译器会优化成StringBuilder，性能没问题。
3.2 循环内+为什么没被优化？
// 你写的代码Strings="";for(inti=0;i<10;i++){s+=i;}// 编译器处理后的真实代码（等价于）Strings="";for(inti=0;i<10;i++){StringBuildertemp=newStringBuilder();temp.append(s).append(i);s=temp.toString();// 每次循环都 new 一个 StringBuilder + 一次 toString}问题核心：编译器把+=翻译成「新建StringBuilder→append→toString」，每次循环都新建对象，无法复用。
3.3 字节码视角
用javap -c查看字节码，循环内的+每次都会：
new一个StringBuilder- 调用
invokevirtual StringBuilder.append - 调用
invokevirtual StringBuilder.toString生成新String
而手动使用StringBuilder：
- 只
new一次 - 循环中只调用
append
3.4 Java 9+ 的invokedynamic优化
Java 9 引入了更高效的字符串拼接方式，通过invokedynamic调用StringConcatFactory：
// Java 9+ 的编译结果（非循环）Strings="Hello"+name+"!";// 底层调用 StringConcatFactory.makeConcatWithConstants但这个优化同样只适用于单个表达式，循环内依然每次都会触发拼接逻辑。
四、正确写法
4.1 循环拼接：手动使用StringBuilder
// ✅ 正确写法StringBuildersb=newStringBuilder();for(Orderorder:orders){sb.append(order.getId()).append(":").append(order.getStatus()).append(",");}Stringresult=sb.toString();4.2 预估容量：减少扩容开销
// ✅ 如果大致知道最终长度，指定初始容量StringBuildersb=newStringBuilder(orders.size()*32);for(Orderorder:orders){sb.append(order.getId()).append(":").append(order.getStatus()).append("\n");}
StringBuilder内部是char[]，默认容量 16，超出后扩容为旧容量 * 2 + 2，涉及数组复制，影响性能。
4.3 非循环场景：直接用+，让编译器优化
// ✅ 完全没问题，编译器会优化Stringmessage="用户："+user.getName()+"，年龄："+user.getAge();log.info(message);不需要手动改成StringBuilder，反而降低代码可读性。
4.4 复杂拼接：用String.format或文本块（Java 15+）
// ✅ String.format：格式清晰Stringsql=String.format("SELECT * FROM %s WHERE id = %d",tableName,id);// ✅ Java 15+ 文本块（适合 SQL / JSON / HTML）Stringjson=""" { "name": "%s", "age": %d } """.formatted(name,age);五、最佳实践
✅ 字符串拼接选择指南
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 单行简单拼接 | String + | 编译器优化，代码清晰 |
| 循环内拼接 | StringBuilder | 避免重复创建对象 |
| 复杂格式化 | String.format | 可读性最好 |
| SQL / JSON / HTML | 文本块（Java 15+） | 多行字符串支持 |
| 超高性能场景 | StringBuilder+ 预分配容量 | 减少扩容 |
🔍 3 个常见误区
误区 1：「StringBuffer比StringBuilder慢，永远不用」
→ 正确：StringBuffer是线程安全的，多线程共享拼接对象时用它。
误区 2：「所有+拼接都要改成StringBuilder」
→ 正确：只有循环内的拼接需要改，单行拼接编译器已经优化了。
误区 3：「StringBuilder用完要调用toString()再清空」
→ 正确：toString()不影响原StringBuilder，可继续append。
🛠️ IDEA inspections
开启以下检查，让 IDE 帮你找问题：
'+' on different lines→ 警告：多行用+拼接StringBuilder.append()'can be replaced withStringconcatenation→ 提示：单行可简化String concatenation in loop→错误：循环中字符串拼接（最重要！）
六、小结
- 单行/单个表达式内的
+拼接：编译器自动优化成StringBuilder，性能无问题 - 循环内的
+=拼接：每次循环创建新StringBuilder+ 新String，性能极差 - 正确做法：循环外创建
StringBuilder，循环内只调用append - 容量预分配：大致知道最终长度时，指定初始容量减少扩容
- Java 9+引入
invokedynamic优化，但循环场景依然需要手动StringBuilder
下一篇预告：重写 equals 不重写 hashCode 会怎样？—— HashMap 里的对象"丢了"，竟然是因为这个原因。
