string循环拼接性能差因其实例不可变，每次+或concat()均新建对象并复制内容，1000次循环产生1000个中间对象，引发频繁gc导致耗时陡增。
为什么String在循环拼接时性能差
Java中String是不可变对象，每次用+或concat()拼接都会新建一个String实例，原字符串内容被复制进新对象。循环1000次拼接，就产生1000个中间String对象，触发频繁GC，耗时陡增。
典型低效写法：
String result = "";
for (int i = 0; i < 1000; i++) {
result += "item" + i; // 每次都创建新String
}
这不是语法错误，但实际运行慢、内存压力大，尤其在日志组装、SQL构建、模板渲染等场景下尤为明显。
StringBuilder.append()的正确调用方式
StringBuilder是线程不安全但高效率的可变字符序列，所有修改都在内部char[]数组上原地进行。关键不是“用了StringBuilder”，而是怎么初始化和调用append()。
立即学习“Java免费学习笔记（深入）”；
- 避免无参构造：默认容量16，扩容会触发数组复制，小概率但可避免
- 预估长度用带初始容量的构造函数，比如拼接100个平均长度20的字符串，建议
new StringBuilder(2000) - 连续
append()比多次toString()后再拼更高效——后者又绕回了String不可变陷阱 -
append()接受boolean、int、char、Object等，无需手动String.valueOf()转换
优化后写法：
StringBuilder sb = new StringBuilder(2000);
for (int i = 0; i < 1000; i++) {
sb.append("item").append(i); // 零对象创建，纯数组位移
}
String result = sb.toString(); // 仅最后一步生成String
StringBuilder vs StringBuffer：别在单线程里用错类型
两者API几乎一致，区别只在同步策略：StringBuffer每个方法都加了synchronized，而StringBuilder完全无锁。这意味着：
- 单线程环境（绝大多数业务代码）必须用
StringBuilder，性能高出2–3倍 - 多线程共享同一实例且需线程安全时，才考虑
StringBuffer；但更推荐拆分作用域或用ThreadLocal<stringbuilder></stringbuilder> - IDEA或Sonar常报“StringBuffer may be replaced with StringBuilder”警告，不是建议，是明确性能提示
错误示范（无必要同步）：
StringBuffer sb = new StringBuffer(); // 不要用
sb.append("a").append("b");
容易被忽略的边界情况：toString()之后别再append
StringBuilder.toString()返回的是一个**新创建的String对象**，它和StringBuilder内部数组完全无关。但很多人误以为“拿到String后还能继续追加”：
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的适用边界……这些不常碰，但一旦出现在高频日志或底层序列化路径里，就很难排查。
