String不可变因其value字段为final byte[]且修改方法均返回新对象；这导致循环拼接会频繁创建临时对象，加剧GC压力。
String 为什么不可变？这直接影响它在多线程和内存中的行为
String 的不可变性不是语法限制，而是由其实现决定的：value 字段是 final byte[]（JDK 9+），且所有修改方法（如 substring()、toLowerCase()）都返回新对象。这意味着每次拼接都会生成新对象，频繁操作会快速堆积临时字符串，触发 GC 压力。
常见误用场景：在循环中用 + 拼接日志或 SQL：
String sql = "SELECT * FROM user WHERE id IN (";
for (int i = 0; i < ids.size(); i++) {
sql += ids.get(i); // 每次都新建 String 对象
if (i < ids.size() - 1) sql += ",";
}
sql += ")";这种写法在 JDK 8 及以前会被编译器自动优化为 StringBuilder，但仅限于**编译期可确定的字符串常量拼接**；一旦涉及变量（如 ids.get(i)），优化就失效。实际运行时仍是 N 次对象创建。
StringBuilder 和 StringBuffer 的核心区别只在 synchronized
两者 API 几乎完全一致，都继承自 AbstractStringBuilder，底层共用 char[] value 和 int count。关键差异仅在于：
-
StringBuffer的所有 public 修改方法（append()、insert()、delete()等）都加了synchronized -
StringBuilder对应方法**完全没加锁**
这意味着：
立即学习“Java免费学习笔记（深入）”；
- 单线程下，
StringBuilder性能通常比StringBuffer高 10%–15%，因为免去了锁开销 - 多线程共享同一个
StringBuilder实例并并发调用append()，结果可能错乱甚至抛ArrayIndexOutOfBoundsException（因count更新未同步） -
StringBuffer虽线程安全，但不等于“适合高并发拼接”——它的锁是实例级的，热点竞争下吞吐会明显下降
什么时候该用 StringBuilder？别被“默认推荐”带偏
面试常答“StringBuilder 是非线程安全的 StringBuilder，所以单线程用它”，但这太笼统。真正决策要看三点：
-
作用域是否跨线程：局部变量（如方法内新建的
StringBuilder sb = new StringBuilder()）天然无共享，选StringBuilder -
是否复用实例：若从池中取、或作为成员变量长期持有，且可能被多个线程调用，则必须用
StringBuffer或加外部同步，否则风险自担 -
性能敏感度：日志拼接、模板渲染等高频路径，优先
StringBuilder；配置加载、初始化阶段拼接一次就完事，用哪个差别不大
一个典型反例：
public class LogUtil {
private static final StringBuilder sb = new StringBuilder(); // ❌ 共享静态实例
public static String format(String msg) {
sb.setLength(0); // 清空
return sb.append("[INFO]").append(msg).toString();
}
}这段代码在多线程下调用会出问题——setLength(0) 和 append() 不是原子操作，两个线程可能交错执行，导致内容混杂或数组越界。
String.intern() 的坑：JDK 7+ 后字符串常量池移到堆里，但仍有强引用风险
intern() 的作用是：如果字符串内容已存在于常量池，则返回池中引用；否则将当前字符串放入池并返回其引用。JDK 7 起，常量池从永久代移到 Java 堆，意味着它受 GC 管理——但仅当没有强引用指向该字符串时才可回收。
容易踩的坑：
- 大量调用
new String("abc").intern()，尤其配合动态生成字符串（如解析 JSON 中的字段名），会导致堆内存中积累大量重复字符串，GC 回收不及时 - 误以为
intern()能解决内存泄漏：它只是去重工具，不能替代对象生命周期管理 - 在 Web 应用中对用户输入做
intern()，可能被恶意构造重复长字符串耗尽堆内存（类似 HashDoS）
除非明确需要字符串引用相等（== 判断），或已确认字符串集合高度重复且总量可控，否则不要主动调用 intern()。
复杂点往往不在“用哪个类”，而在于“谁持有它、生命周期多长、有没有隐式共享”。很多线上 OutOfMemoryError: Java heap space 就源于把 StringBuilder 当缓存长期持有，又忘了清空或复位。
