应使用 StringBuilder 替代 String 拼接，因其在循环中复用同一对象，避免频繁创建临时 String 和 GC 压力；错例中每次 += 都生成新对象，导致 CPU 升高、响应变慢、频繁 Full GC。
String 拼接在循环里为什么越来越慢？
因为每次用 + 或 += 拼接，都会创建一个新 String 对象，旧对象变成垃圾。循环 1000 次，就生成 1000 个中间 String，GC 压力大，内存也浪费。
- 现象：CPU 占用高、响应变慢、频繁 Full GC（看
java -XX:+PrintGCDetails日志能确认） - 场景：日志拼接、SQL 拼装、JSON 字段组装、模板渲染等循环内字符串累积操作
- 错例：
String sql = ""; for (int i = 0; i —— 这实际做了约 50 万次字符复制
StringBuilder.append() 怎么用才不白换？
不是只要换成 StringBuilder 就一定快，关键在初始化容量和复用方式。
- 避免默认构造：
new StringBuilder()初始容量只有 16，扩容要数组拷贝（Arrays.copyOf），频繁扩容反而拖累性能 - 预估长度更高效：
new StringBuilder(2048)或new StringBuilder(sql.length() + expectedAppendSize) - 别在循环外反复
new：如果方法被高频调用，考虑复用对象（注意线程安全——单线程可用局部变量，别塞进 static 字段） - 示例对比：
StringBuilder sb = new StringBuilder(512); for (int i = 0; i → 一次分配，零拷贝扩容
StringBuffer 和 StringBuilder 到底该选谁？
99% 的情况选 StringBuilder；只有明确需要多线程共享并修改同一个对象时，才用 StringBuffer。
-
StringBuffer每个 public 方法都加了synchronized，单线程下纯属锁开销，实测比StringBuilder慢 1.5–2 倍 - 常见误用：把
StringBuilder放进static字段供多个线程共用 → 不加锁会数据错乱，加锁又回到StringBuffer的性能，还更难 debug - 真正需要线程安全的场景极少，多数可通过方法参数传入、局部新建、或用
ThreadLocal<stringbuilder></stringbuilder>替代
toString() 调用时机和内存泄漏风险
StringBuilder.toString() 看似简单，但返回的 String 会持有内部 char[] 的完整引用 —— 如果你只想要其中一段，却长期持有整个 StringBuilder 的结果，可能意外留住大数组。
立即学习“Java免费学习笔记（深入）”；
- 风险代码：
String huge = new StringBuilder().append(hugeData).toString(); // huge 引用着整个 char[] - 优化写法：如果只需要子串，用
substring()后立刻丢弃原始引用，或直接用new String(charArray, offset, len)拷贝所需部分 - 特别注意日志框架（如 Logback）中自动 toString() 的地方：避免把未清理的
StringBuilder直接传给logger.debug("{}", sb)，它可能缓存或打印前不释放
String += 里。 
