String循环拼接性能差因其实例不可变，每次+或concat()均新建对象并复制内容，1000次循环产生1000个中间对象，引发频繁GC导致耗时陡增。

为什么String在循环拼接时性能差

Java中String是不可变对象，每次用+或concat()拼接都会新建一个String实例，原字符串内容被复制进新对象。循环1000次拼接，就产生1000个中间String对象，触发频繁GC，耗时陡增。

典型低效写法：

StringBuilder

• 避免无参构造：默认容量16，扩容会触发数组复制，小概率但可避免
• 预估长度用带初始容量的构造函数，比如拼接100个平均长度20的字符串，建议new StringBuilder(2000)
• 连续append()比多次toString()后再拼更高效——后者又绕回了String不可变陷阱
• append()接受boolean、int、char、Object等，无需手动String.valueOf()转换

优化后写法：

StringBuffer

• 单线程环境（绝大多数业务代码）必须用StringBuilder，性能高出2–3倍
• 多线程共享同一实例且需线程安全时，才考虑StringBuffer；但更推荐拆分作用域或用ThreadLocal
• IDEA或Sonar常报“StringBuffer may be replaced with StringBuilder”警告，不是建议，是明确性能提示

错误示范（无必要同步）：

StringBuffer sb = new StringBuffer(); // 不要用
sb.append("a").append("b");

容易被忽略的边界情况：toString()之后别再append

StringBuilder.toString()返回的是一个**新创建的String对象**，它和StringBuilder内部数组完全无关。但很多人误以为“拿到String后还能继续追加”：

Instagram Content Ideas Generator

使用3×3×10框架生成90+个个性化Instagram内容创意，用AI编辑器精选最佳创意，并将获胜者扩展为可操作的简洁内容。

下载

StringBuilder sb = new StringBuilder("start");
String s = sb.toString(); // s是一个独立String
sb.append("more"); // ✅ 这行仍有效
s.concat("extra"); // ❌ 对s操作不影响sb，且又新建String

真正危险的是这种写法：

StringBuilder sb = new StringBuilder();
String result = sb.toString();
// 后续忘了sb还在用，直接对result操作，结果拼接逻辑断掉

更隐蔽的问题：某些工具类（如旧版Apache Commons Lang的StringUtils.join()）内部用StringBuilder，但返回String后你若想复用该builder，得自己保留引用——库不会帮你留。

复杂点在于：扩容阈值、Unicode代理对、setLength(0)重用技巧、与StringJoiner的适用边界……这些不常碰，但一旦出现在高频日志或底层序列化路径里，就很难排查。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南