Java中字符串拼接用+慢因String不可变，每次拼接都新建对象并触发GC；StringBuilder可变且内部用数组缓存，append仅填数据，性能高两个数量级。
为什么直接用 + 拼接字符串在循环里会变慢
Java 中 String 是不可变的，每次用 + 拼接都会新建一个对象。循环 10000 次，就可能创建上万个临时 String 对象，触发频繁 GC，CPU 和内存压力都明显上升。
而 StringBuilder 是可变的，内部用 char[]（或 Java 9+ 的 byte[]）缓存内容，append() 只是往数组里填数据，扩容也按需发生（默认初始容量 16，翻倍增长）。
实测：拼接 5 万次短字符串，+ 耗时约 800ms，StringBuilder 约 3ms —— 差两个数量级不是夸张。
初始化 StringBuilder 时该不该指定 capacity
应该，尤其当你大概知道最终字符串长度时。不指定就用默认 16，循环中反复扩容（复制数组）会吃掉一部分性能优势。
估算方法：把各段字符串长度加起来，再加 10%~20% 余量。比如拼接 1000 条日志，每条平均 80 字符，预估 new StringBuilder(1000 * 80 + 2000)。
- 低估 capacity → 多次扩容，但影响有限（毕竟只是数组拷贝）
- 高估太多 → 浪费内存，但通常不致命
- 完全不设 → 小数据无感，大数据下扩容次数可能达 log₂(N) 级别
循环内 append() 后要不要 toString() 或 setLength(0)
只在循环结束后调用一次 toString()。循环中反复调用它，等于每次都在生成新 String 对象，白用了 StringBuilder。
如果要复用同一个 StringBuilder 做多次拼接（比如批量处理多个列表），用 setLength(0) 清空内容比 new StringBuilder() 更轻量 —— 它不释放底层数组，只是重置长度指针。
注意：setLength(0) 不等于 delete(0, length())，前者更快；但若之后 append 的内容远小于原数组容量，也不必主动 trimToSize()，除非内存敏感。
StringBuilder 在多线程环境下能直接共享吗
不能。StringBuilder 不是线程安全的，没有同步机制。多线程并发 append() 可能导致内容错乱、越界异常，甚至静默丢数据。
替代方案只有两个：
- 每个线程用独立的
StringBuilder实例（推荐，无锁无争用） - 换成
StringBuffer（方法加了synchronized，但性能下降约 10%~15%，且多数场景没必要）
还有一种常见误用：把 StringBuilder 当作全局缓存对象反复 append + setLength(0)，却没考虑调用方是否单线程 —— 这种“伪复用”在 Web 应用里极易引发偶发 bug。
真正要注意的，不是语法会不会写，而是生命周期管理：谁创建、谁初始化 capacity、谁负责清空、谁保证线程隔离。这些细节漏掉一个，性能收益就可能归零，甚至引入隐蔽问题。
