String拼接变慢是因为其不可变性导致每次拼接都新建对象并复制内容，10万次循环产生大量临时对象加重GC压力；StringBuilder通过可变字符数组和预扩容机制提升性能，但需注意线程安全、初始容量及toString()的内存开销。
String 为什么一拼接就变慢？
因为 String 是不可变的（immutable）——每次用 + 或 concat() 拼接，JVM 都会新建一个 String 对象，把旧内容复制过去再加新内容。10 万次循环拼接，就可能产生 10 万个临时对象，GC 压力陡增，耗时爆炸。
- 常见错误现象：
str += "a"在循环里用，性能比StringBuilder.append("a")慢几十倍甚至上百倍 - 底层真相：编译器会把
str += "a"自动转成new StringBuilder(str).append("a").toString()，每次循环都 new 一次，纯属浪费 - 适用场景：只读字符串、常量定义、方法参数传递（比如
log.info("user id: {}", userId)中的字面量）
StringBuilder 是怎么把性能拉回来的？
StringBuilder 是可变的字符序列，内部用一个非 final 的 char[]（或 JDK 9+ 的 byte[]）存数据，append() 直接往数组末尾写，扩容时才新建数组并复制——次数极少，开销可控。
- 关键优势：单线程下无锁、无同步，比
StringBuffer快约 10%–15% - 必须注意容量：默认初始容量是 16，如果拼接结果远超这个数（比如拼 10KB JSON），频繁扩容会触发多次数组复制；建议构造时预估长度：
new StringBuilder(4096) - 别忘了
toString()：它返回的是新String对象，不是引用原缓冲区，所以后续修改StringBuilder不会影响已生成的字符串
什么时候不该用 StringBuilder？
不是所有字符串操作都适合 StringBuilder。它解决的是「多次修改同一逻辑字符串」的问题，不是万能胶水。
- 拼接两个固定字符串？直接用
"a" + "b"—— 编译期就优化成常量，比运行时 newStringBuilder更快 - 需要线程安全？别硬上
StringBuilder，要么加外部锁（不推荐），要么换StringBuffer（但得确认真有并发写入） - 只是做查找、截取、替换？
String的substring()、replace()、split()已经足够高效，没必要先转成StringBuilder再操作
一个容易被忽略的坑：toString() 后的字符串不再共享底层数组
JDK 7u6 之后，String 的构造不再共享 char[]（即废除了“字符串切片复用底层数组”的优化），所以 new StringBuilder("hello world").substring(0, 5).toString() 一定会拷贝一份新数组。这本身没问题，但如果你误以为 toString() 返回的是轻量引用，就可能在高频日志场景中无意放大内存压力。
立即学习“Java免费学习笔记（深入）”；
- 验证方式：用
Unsafe或 JOL 工具看对象内存布局，或观察 GC 日志中char[]实例数突增 - 对策：若需大量短生命周期字符串，且内容高度重复（如固定前缀+递增ID），考虑用
String.intern()，但注意字符串常量池在 JDK 7+ 后移到堆中，滥用仍可能导致 OOM
StringBuilder 的构造参数和 toString() 的语义，比背熟三者区别更管用。 
