17370845950

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" —— 编译期就优化成常量，比运行时 new StringBuilder 更快
• 需要线程安全？别硬上 StringBuilder，要么加外部锁（不推荐），要么换 StringBuffer（但得确认真有并发写入）
• 只是做查找、截取、替换？String 的 substring()、replace()、split() 已经足够高效，没必要先转成 StringBuilder 再操作

一个容易被忽略的坑：toString() 后的字符串不再共享底层数组

JDK 7u6 之后，String 的构造不再共享 char[]（即废除了“字符串切片复用底层数组”的优化），所以 new StringBuilder("hello world").substring(0, 5).toString() 一定会拷贝一份新数组。这本身没问题，但如果你误以为 toString() 返回的是轻量引用，就可能在高频日志场景中无意放大内存压力。

• 验证方式：用 Unsafe 或 JOL 工具看对象内存布局，或观察 GC 日志中 char[] 实例数突增
• 对策：若需大量短生命周期字符串，且内容高度重复（如固定前缀+递增ID），考虑用 String.intern()，但注意字符串常量池在 JDK 7+ 后移到堆中，滥用仍可能导致 OOM

真正卡住性能的，往往不是“该用哪个类”，而是没想清楚「这个字符串到底要被改几次」「谁在读、谁在写」「生命周期有多长」。多看一眼 StringBuilder 的构造参数和 toString() 的语义，比背熟三者区别更管用。