String、StringBuilder、StringJoiner底层原理与性能对比解析

1. 三个类躺在同一张考卷上：先弄清它们各自存在的理由

很多Java开发者入门时都背过这样一句口诀：String是不可变的，StringBuilder是可变的，StringJoiner是Java 8以后加的。但如果面试官继续追问一句"为什么有了String还要有StringBuilder，有了StringBuilder还要专门出一个StringJoiner"，不少人就开始含糊了。

这三个类并不是同一功能的三个版本，而是针对三种完全不同场景分别设计的。String解决的是"字符串作为常量被安全共享"的问题，StringBuilder解决的是"循环里反复拼接字符串不能每次新建对象"的问题，StringJoiner解决的则是"拼接时还要带上分隔符、前缀、后缀"这种更具体的格式需求。理解它们各自的出发点，比死记底层源码重要得多。

先说String。String对象在Java里承担着"常量"的职能，因为字符串在代码里出现的频率太高了，如果每次声明一个相同的字面量都要在堆里新建一个对象，内存很快就会失控。所以JVM设计了字符串常量池，让内容相同的字面量尽量复用同一个对象。而要做到"复用"这件事，就必须保证对象内容不会被修改，否则一个线程改了字符串内容，所有引用这个对象的地方全跟着变，这种全局灾难是任何系统都承受不起的。所以String被设计为不可变类，final修饰类、final修饰char[]数组、所有修改操作都返回新对象，这是为了让"安全共享"成为可能。

StringBuilder则完全是另一个方向。它解决的是"可变缓冲区"的问题。设想一个循环里要拼接10000次字符串，如果用String的+号，每一次拼接都会产生一个新的String对象，旧的String对象被丢弃等待垃圾回收。这种高频创建对象的成本在GC压力大的时候非常可观，尤其在服务端高并发场景下，频繁Young GC甚至会影响整体响应时间。StringBuilder的做法是内部维护一个可变字符数组，拼接操作直接在数组后面追加内容，数组不够了再扩容，整个过程不会产生中间String对象。所以它的设计目标非常明确：牺牲线程安全，换取拼接效率。

StringJoiner看起来和StringBuilder很像，但它解决的是另一个具体问题。很多时候我们不光要拼接，还要在每两个元素之间插入分隔符，比如把列表拼成a, b, c，或者拼成JSON风格的[1, 2, 3]。如果手工用StringBuilder写，需要每次判断是不是第一个元素来决定要不要加分隔符，代码啰嗦且容易出错。StringJoiner把"前一个元素和后一个元素之间加分隔符"这件事封装起来，还额外支持前缀后缀，让你直接声明目标格式，内部本质上还是基于StringBuilder在做追加。

弄清这三个类的定位之后，再去读源码就会顺畅得多。接下来我会从底层存储、内存分配、扩容机制、设计取舍四个方面拆开讲，最后再给出一组可复现的实测对比和面试高频考点。

2. String的底层存储：从char[]到byte[]的演进与常量池分配逻辑

2.1 JDK 8与JDK 9+的存储结构差异

很多老教程到现在还在说"String底层是char[]数组"，这话放在JDK 8时代完全正确，但JDK 9开始就已经变了。

JDK 8及之前，String内部确实是一个final char value[]数组，每个字符占用2个字节，不管这个字符是纯英文字母还是中文字符，统一按UTF-16编码存储。这在大多数场景下是巨大的浪费，因为应用程序里大量字符串其实是拉丁字符，一个英文字符用UTF-16编码只需要1个字节，但char强行占用2个字节，内存直接翻倍。

JEP 254从JDK 9开始引入了compact strings（紧凑字符串）。String内部不再只有char[]一种形态，而是改成了byte[] value加一个byte coder字段。coder字段用来标记这个字符串是LATIN1编码还是UTF16编码。当字符串内容全部由Latin-1字符集（也就是单字节就能表示的字符）组成时，coder为0，存储时每个字符只占1字节；只要出现一个需要2字节表示的字符，coder就变为1，整个数组按UTF-16存储。

这个改动对内存的节省是非常可观的。我做过一个粗略估算：假设一个服务里有10万个平均长度20字符的纯英文日志字符串，JDK 8下每个字符串至少占40字节数据空间，JDK 9开始只需要20字节，光字符串内容部分就省了一半。虽然对象头、数组头还有额外开销，但整体降幅依然明显。这也是为什么很多从JDK 8迁移到JDK 11或17的项目，在堆内存不变的情况下，字符串相关的内存占用直觉上变低了。

不过要小心一点：compact strings是JVM内部的自动优化，对应用层透明，但如果你在代码里强行用反射去读取String的value字段，不同JDK版本的字段类型不一样，代码可能直接崩。我在实际项目里就见过有人用反射去"修改"String内容来实现某些黑魔法，JDK版本一升级，代码直接抛NoSuchFieldError。这种操作本来就不该做，后面会解释为什么危险。

2.2 字符串常量池到底在哪块内存

字符串常量池的位置在JDK演进中发生过一次非常重要的调整。JDK 6及之前，字符串常量池放在方法区（PermGen永久代）里。永久代有一个很烦人的特性：空间有限，而且默认情况下不可回收。所以如果你代码里不停地调用intern()往池子里塞新的字符串，很容易把永久代塞满，抛OutOfMemoryError: PermGen space。

JDK 7开始，字符串常量池被移到了堆中。这个调整意义重大：字符串对象本身在堆里，常量池的引用关系也在堆里，整个生命周期受堆内存管理统一支配，永久代满了的问题不再影响字符串常量池。同时，由于池子在堆里，当堆空间紧张时，池中被引用不到的内容是可以被垃圾回收的。

到了JDK 8，永久代被彻底移除，取而代之的是元空间（Metaspace）。但字符串常量池并没有跟着搬到元空间，而是稳定地留在堆里。这一点面试时经常被问到，答案要记准确：JDK 7以后字符串常量池在堆中，元空间存放的是类的元数据、方法字节码、运行时常量池的符号引用等信息，字符串常量池的实体已经在堆里了。

字符串常量池里存的是字符串对象还是引用？这个细节很多人搞混。准确说法是：池里存放的是字符串对象的引用。当你用双引号字面量写一个字符串时，JVM会先检查常量池中是否已有内容完全相同的字符串对象，如果有，直接返回该对象的引用；如果没有，就在堆中创建这个字符串对象，并把引用放入常量池。这样设计的好处是，堆里的字符串对象只保留一份，多个引用指向同一个对象。

看一下常见的创建方式：

java复制String s1 = "hello";
String s2 = "hello";
String s3 = new String("hello");
String s4 = s3.intern();
System.out.println(s1 == s2); // true
System.out.println(s1 == s3); // false
System.out.println(s1 == s4); // true

s1和s2都是字面量，常量池中命中同一个对象，所以==为true。s3用new创建，JVM会先在常量池里看了一眼发现已有"hello"对象，这一步只是确认，随后在堆中强制创建一个全新的String对象，所以s3和s1肯定不是一个对象。s4调用intern()，返回的是常量池中的对象引用，所以和s1为同一个对象。

理解了这个机制，后面讲内存分配时就不会糊涂。

2.3 intern()：手动入池的副作用与风险

intern()方法的作用是：如果常量池中已经有内容相同的字符串，直接返回池中对象的引用；如果没有，把当前字符串对象的内容加入池中并返回引用。

听起来很方便，但工程上要谨慎使用。JDK 7以前使用intern()需要格外小心，因为池子在永久代，空间小且不回收，大量不同内容的字符串入池很容易把永久代塞爆。JDK 7以后池子在堆里，虽然可回收，但大批量intern()依然会带来明显的性能损耗——每次入池都需要在池里做内容比对，这个比较是字符串内容级别的，不是引用级别的。如果你的字符串内容很长，频繁intern()的CPU开销会非常惊人。

有一种相对稳妥的使用方式：只对有限集合的字符串做intern()，比如枚举值、状态码、固定字典项。这种场景下缓存命中率高，反复入池的机会少，省内存的效果也明显。反之，把用户输入、日志详情、SQL语句这类无限变化的字符串拿去intern()，不是内存爆掉就是CPU被打满，属于典型的反向优化。

另外要强调一点，永远不要用反射修改String的内容。String设计为不可变，所有的安全机制、哈希缓存、常量池共享都建立在"内容不变"这个前提上。一旦通过反射改了内部数组，可能出现同一个"常量"在两处表现出不同值的情况，轻则业务结果错乱，重则JVM内部数据不一致直接崩溃。这种代码在面试里可以讲原理，在生产环境千万不要碰。

3. StringBuilder扩容机制与线程安全：一段高频拼接代码背后的计算

3.1 构造器与容量增长的过程

StringBuilder的核心是一个byte[] value数组（JDK 9以后，存储结构跟随String的compact strings改动也变成了byte[]），所有字符都存在这个数组里。数组长度就是当前缓冲区容量，而实际已经使用的字符数用int count记录。

先看两个常用构造器：

java复制public StringBuilder() {
    super(16);
}

public StringBuilder(int capacity) {
    super(capacity);
}

无参构造器默认容量是16。也就是说，如果你直接new StringBuilder()然后往里追加字符，前16个字符不会触发扩容。一旦超过16，就会走扩容逻辑。而如果你预计要拼接的内容长度会超过16，比如循环里拼100个字段，最好用new StringBuilder(预估长度)直接指定初始容量，减少扩容次数。

为什么默认是16而不是别的数字？这属于JDK早期设计者拍板的一个折中值。16个字符对大多数短拼接场景够用，既不会因为一开始分配过大浪费内存，也不会因为过小频繁扩容。实际开发中如果无法预估大小，就用默认值；能预估的话，一定要指定容量。数组扩容不是免费的，每次扩容都要申请新数组、拷贝旧数据、抛弃旧数组，这些操作在高频路径上都是实实在在的CPU和内存开销。

3.2 扩容为什么是 oldCapacity * 2 + 2

当count达到value.length时，StringBuilder会调用newCapacity()方法。源码逻辑大致如下：

java复制int newCapacity = (oldCapacity << 1) + 2;

也就是oldCapacity * 2 + 2。比如容量从16扩到34，再从34扩到70，每次大约翻倍。

为什么是*2+2而不是+16这样固定增长？这和ArrayList扩容思路类似。固定增长的问题是：如果增长量太小，大量元素需要多次扩容，拷贝成本累计很高；如果增长量太大，可能一次就多分配了几百个字符的空间，浪费内存。翻倍增长是一种折中：扩容次数以对数级别减少，最多浪费的空间不超过当前数组容量的一半。至于为什么加2，可以理解为给后续追加留一点点余量，也有人说这是为了兼容旧版本实现中的一些边界情况。从工程角度看，记结论就行：StringBuilder容量不足时近似翻倍扩容，整体均摊下来每次追加操作的时间复杂度是O(1)。

看一个扩容触发过程的简单例子：

java复制StringBuilder sb = new StringBuilder(); // 容量16
for (int i = 0; i < 100; i++) {
    sb.append("a");
}

第17次append时触发第一次扩容，数组从16扩到34；之后字符串总长度超过34时再扩到70；再之后超过70扩到142。也就是说这个循环最多扩容3次。如果一开始就设置new StringBuilder(100)，这个100次追加的过程中一次扩容都不会发生。

从性能角度说，能预估容量就预估，这是最简单也最有效的优化手段。

3.3 线程不安全的真实场景

StringBuilder的append、insert、toString这些方法都没有加锁，因为它就是设计为单线程使用的。常见的说法是"StringBuilder线程不安全，StringBuffer线程安全"，这个说法本身没错，但很多人不理解到底不安全在哪里。

看这段代码：

java复制public class Counter {
    private StringBuilder sb = new StringBuilder();

    public void add(String s) {
        sb.append(s);
    }
}

两个线程同时调用add()，实际执行的是append()。append内部会执行几步操作：读取count、在count位置写入字符、更新count为新值。如果两个线程同时读到同一个count值，后写入的内容会覆盖前一个线程的内容，或者count值被更新错乱，最终字符串内容丢失、乱序甚至数组越界。

更隐蔽的问题是扩容场景。假设两个线程同时发现count已经等于value.length，都进入扩容逻辑，各自生成一个新数组并尝试替换成员变量value。后完成替换的线程会把先完成替换的线程的新数组覆盖掉，导致已经写入的数据丢失，而且两个线程后续操作可能基于不同的数组引用，状态彻底错乱。

所以并发场景下要么用StringBuffer，要么自己加锁，要么使用ThreadLocal隔离。StringBuffer的线程安全是通过在每个方法上加synchronized实现的，代价是每次调用都要获取锁，单线程下性能比StringBuilder差不少。我实测过在单线程循环100万次拼接的场景下，StringBuffer比StringBuilder慢30%左右。所以判断很简单：没有并发需求，就用StringBuilder；有并发需求，优先考虑加锁或线程隔离，而不是直接无脑上StringBuffer，因为StringBuffer只是把线程安全问题变成了弱并发下的串行热点，在高竞争环境下锁的代价同样不小。

4. StringJoiner：前缀、后缀与分隔符的设计取舍

4.1 两个构造器分别解决什么问题

StringJoiner是Java 8才加入的，它本身内部没有维护原始字符数组，而是组合了一个StringBuilder作为实际存储。JDK源码里它的字段包括：

java复制private final String prefix;
private final String delimiter;
private final String suffix;
private StringBuilder value;
private String emptyValue;

两个构造器：

java复制public StringJoiner(CharSequence delimiter)
public StringJoiner(CharSequence delimiter, CharSequence prefix, CharSequence suffix)

第一个只传分隔符，等价于前缀为""、后缀为""的简化版本。第二个传分隔符外加前缀后缀，主要面向那些需要格式化输出的场景。

举个最典型的例子：把元素拼成[1, 2, 3]这种格式。传统写法是：

java复制StringBuilder sb = new StringBuilder("[");
for (int i = 0; i < list.size(); i++) {
    if (i > 0) {
        sb.append(", ");
    }
    sb.append(list.get(i));
}
sb.append("]");

用StringJoiner直接写：

java复制StringJoiner joiner = new StringJoiner(", ", "[", "]");
for (Integer item : list) {
    joiner.add(item.toString());
}
String result = joiner.toString();

第二个写法明显更清晰地表达了"我要生成的格式"，而不是把这个格式拆分到循环逻辑里。这就是StringJoiner存在的意义：把分隔符、前缀、后缀的拼接规则从业务代码里抽离出来，降低出错概率。

4.2 add、merge与toString的内部行为

add(CharSequence newElement)方法内部本质上是调用底层StringBuilder的append：如果当前还没有加入过任何元素，就直接把前缀加分隔符的规则挂起，先追加newElement内容；如果已经有元素了，先追加delimiter，再追加newElement。源码大致逻辑如下（简化）：

java复制public StringJoiner add(CharSequence newElement) {
    prepareBuilder().append(newElement);
    return this;
}

private StringBuilder prepareBuilder() {
    if (value != null) {
        value.append(delimiter);
    } else {
        value = new StringBuilder().append(prefix);
    }
    return value;
}

注意这个细节：value为null表示还没有加入过任何元素。第一次add时，新建StringBuilder并先追加prefix。第二次及之后的add，先追加delimiter再追加新元素。最后一个元素之后不会自动追加后缀，后缀是在toString()时才加上的。

这样设计的原因是：StringJoiner不知道你什么时候会停止add。它在toString这个方法里才组装最终结果，可以避免每次add都要判断"这是不是最后一个，是的话要追加后缀"。这个"懒组装"的思路值得学习——在不知道集合何时结束的场景下，推迟到输出阶段再做收尾处理，可以省掉大量无意义的中间状态判断。

merge(StringJoiner other)方法用于把另一个StringJoiner的内容合并进来。合并的语义是：如果other为空，什么都不做；如果other不为空，把other中已添加的元素按当前this的分隔符规则追加到this中。注意合并时other自己的前缀和后缀会被忽略，只取其中的元素和元素之间的分隔内容。

toString()方法不是简单的value.append(suffix)就返回。它做了空值处理：

java复制public String toString() {
    if (value == null) {
        return emptyValue;
    }
    if (suffix.equals("")) {
        return value.toString();
    }
    int initialLength = value.length();
    StringBuilder result = value.append(suffix);
    value.setLength(initialLength);
    return result.toString();
}

这里有个很有意思的细节：它在尾部追加后缀后，又用setLength把新追加的后缀从value里移除。原因是StringJoiner可以被复用——每次toString之后，你还是可以继续add新的元素，不影响下一次输出。如果直接把后缀append进去不撤销，那么下次add时元素会被追加到后缀后面，格式就全乱了。用setLength回滚是一种跑完即恢复的临时拼接技巧。

4.3 与String.join的关系和区别

很多人知道有个String.join(CharSequence delimiter, CharSequence... elements)方法，它是Java 8和StringJoiner一起引入的。两者的关系是：String.join底层就是用StringJoiner实现的。

java复制public static String join(CharSequence delimiter, CharSequence... elements) {
    Objects.requireNonNull(delimiter);
    StringBuilder sb = new StringBuilder();
    sb.append(elements[0]);
    for (int i = 1; i < elements.length; i++) {
        sb.append(delimiter);
        sb.append(elements[i]);
    }
    return sb.toString();
}

这是JDK 8中可以查到的实现。不过还有一个细节：String.join用StringJoiner实现时，会像上面这段代码一样自己构建吗？实际上JDK 8中join的实现依赖了一个内部方法，本质上和StringJoiner的机制一致。无论细节怎么变，结论是：String.join适合"只有分隔符、没有前缀后缀"的简单场景；StringJoiner适合"有分隔符又要前缀后缀"的格式化场景。

另外注意String.join要求至少传入一个元素，如果传入空数组会抛异常。不想抛异常的话，判断一下集合是否为空再调用，或者直接用StringJoiner自己处理空值场景，这样更安全。

还有一个与Stream结合的使用方式：

java复制list.stream()
    .collect(Collectors.joining(", ", "[", "]"));

Collectors.joining底层就是StringJoiner。所以知道了StringJoiner的前缀后缀、分隔符行为，就理解了Stream里joining的语义。joining()、joining(delimiter)、joining(delimiter, prefix, suffix)三个重载分别对应StringJoiner的两个构造器。

5. 从代码到内存：用一组实验看清分配位置与性能差异

5.1 不同创建方式在内存中的指向关系

为了把内存分配讲透彻，我画一张文字版的内存指向图来说明。

假设代码中有这样几行：

java复制String a = "hello";
String b = new String("hello");
String c = b.intern();

内存中有三块区域需要关注：栈、堆、字符串常量池（在堆内）。

• 栈中保存局部变量a、b、c，它们是引用类型变量，占8字节。
• a指向字符串常量池中的"hello"对象。
• new String("hello")首先检查常量池，发现"hello"已存在，于是这个字面量对象就用池里的；然后在堆中新建一个String对象，内容一样，但引用不同。b指向堆中的这个新对象。
• c调用intern()后，返回常量池中已有"hello"对象的引用，所以c和a指向同一个对象。

这个指向关系解释了为什么a == b是false、a == c是true。从内存分配角度理解：常量池对象和堆对象虽然内容相同，但是两个不同对象，地址不同，==比较的是地址。

还有一类容易忽略的情况：如果先有new String("hello")，再执行intern()，JDK 7以后有一个优化——intern()发现池中没有内容相同的对象时，会把当前堆中对象的引用直接记录到池里，而不是复制一份内容到池中。也就是说，池里存放的引用可能指向一个原本由new创建的对象。这个优化让字符串对象在堆中只有一份实体。

5.2 拼接性能实测与解释

我在本地用一个简单的基准测试对比了三种拼接方式在10万次循环中的表现。测试环境是JDK 17，循环体内反复拼接"a"字符。

方式一：直接使用+号

java复制String s = "";
for (int i = 0; i < 100000; i++) {
    s = s + "a";
}

方式二：使用StringBuilder

java复制StringBuilder sb = new StringBuilder(100000);
for (int i = 0; i < 100000; i++) {
    sb.append("a");
}
String s = sb.toString();

方式三：使用StringBuffer

java复制StringBuffer sbf = new StringBuffer(100000);
for (int i = 0; i < 100000; i++) {
    sbf.append("a");
}
String s = sbf.toString();

实测结果大致是：方式一耗时是方式二的几十甚至上百倍，方式三比方式二慢20%到40%。方式一慢的原因很直观：每轮+都会创建一个新的String对象，10万次循环创建了10万个中间字符串对象，每个对象都是前一轮结果的完整拷贝。这些对象不仅需要分配内存，还要在GC时被回收。10万个对象的分配、拷贝、回收叠加在一起，性能和内存开销都极高。

方式二只创建一个StringBuilder，一个最终String对象，中间没有任何多余对象，所以最快。方式三因为每轮append都要走一次synchronized，锁的获取和释放本身有开销，尽管JVM对无竞争锁做了偏向锁优化，但仍然比无锁慢。

这里要额外说一句：如果循环内的拼接是"str" + 常量，或者多个字符串常量直接写在一行里，编译器会帮你优化成一次StringBuilder操作。但循环中的拼接因为无法在编译期确定次数，编译器不会自动优化。所以别指望编译器救你，该用StringBuilder的地方一定要用。

5.3 编译期拼接的优化规则

JVM编译时对字符串拼接有一套路数。先看最简单的情况：

java复制String s = "a" + "b" + "c";

这种全部由字面量组成的表达式，在编译期就被直接合并为"abc"，运行时不会产生任何拼接操作。这个优化在javac编译阶段就会做，证书可以反编译class文件查看常量池里只有"abc"。

再看带有变量的情况：

java复制String a = "a";
String b = "b";
String result = a + b;

JDK 8及以前，javac会把a + b编译成new StringBuilder().append(a).append(b).toString()。JDK 9开始，引入了一个叫invokedynamic的机制，靠StringConcatFactory来动态决定拼接策略。这样做的目的是把拼接的优化决策从编译期推迟到运行期，JIT可以根据运行时情况选择更合适的拼接方式，比如直接计算最终长度一次性分配数组，而不是先创建StringBuilder再扩容。

不过这些编译器优化只针对单次拼接表达式，不针对循环体内动态增长的拼接。在实际开发中记住这个规律：同一行内的多个字符串拼接可以放心用+，编译器会处理好；循环或者递归中累积字符串，必须用StringBuilder或StringJoiner。

6. 面试考点与开发避坑：把底层知识落到工程里

6.1 高频面试题整理

结合目前网上常见的Java面试题和我在团队里实际问过的题目，整理几个最能考察底层理解的问题：

问题1：String为什么设计为不可变？
关键得分点有三个：一是常量池复用的需要，内容可变会导致共享对象被意外修改；二是线程安全，不可变对象天然可以安全地跨线程共享，不需要加锁；三是安全性，String经常作为HashMap的key、类加载的路径、网络协议参数等，如果内容可变，哈希值会在对象生命周期内变化，导致HashMap查不到对应条目。

问题2：为什么循环拼接字符串要用StringBuilder而不是+？
核心是对象创建频率。+在循环中每次都会创建新的String对象，O(n)个中间对象带来O(n)的分配和GC开销，整体复杂度从O(n)退化成O(n^2)。StringBuilder通过可变缓冲区和扩容机制，均摊复杂度为O(1)追加。

问题3：StringBuilder扩容机制是怎样的？
默认容量16；容量不足时新容量为oldCapacity * 2 + 2；扩容需要申请新数组、拷贝旧数据、释放旧数组。实际开发中预估容量可以显著减少扩容次数。

问题4：new String("abc")创建了几个对象？
两个考察点：一是如果常量池中已有"abc"，则只在堆中创建一个新对象；二是如果常量池中没有"abc"，那么创建两个对象——常量池中的字面量对象和堆中的String对象。注意String对象内容其实引用的是内部byte[]数组，这个细节可以顺带提一句展示深度。追问时还可能提到intern()。

问题5：StringBuilder和StringBuffer有什么区别？
StringBuilder线程不安全但性能高，StringBuffer线程安全但性能略低。选择依据是是否有并发修改同一个缓冲区的需求。但并发场景下更推荐通过线程隔离来避免锁竞争，而不是直接依赖StringBuffer。

问题6：StringJoiner什么时候用？
需要拼接的元素之间有分隔符，且可能还带前后缀时。比如打印集合、生成CSV行、构造SQL的IN子句。Collectors.joining底层也是它。

6.2 开发中的常见误用

第一类误用：无脑在循环里用+拼接。这在请求日志、批量报文、大列表转字符串的场景中很要命。我见过一个线上服务因为日志框架里拼接了一条超长报文的行，导致频繁Full GC，QPS直接掉了一半。换成StringBuilder之后就恢复了正常。

第二类误用：滥用intern()。有些开发者听说intern能省内存，就把用户输入、接口参数全部intern一遍。结果不同内容的字符串数量巨大，互不命中，池子越来越大，比对开销极高，反而把内存和CPU都打爆了。正确做法是只在有限枚举值上使用。

第三类误用：用StringBuilder去拼JSON或XML。这类格式化拼接看起来能用StringBuilder实现，但手写转义、嵌套、格式化非常容易出错。结构化的内容应该用专门的序列化库，StringBuilder适合的是一维的、以简单分隔符相连的文本。

第四类误用：以为new String("abc")一定创建两个对象。在常量池已有"abc"时只创建一个堆对象，在常量池没有时才会创建两个对象。虽然业务代码里很少故意写new String("abc")，但读代码、写框架、做性能分析时这点细节常常是判断一个人基础扎不扎实的试金石。

第五类误用：忽略了StringJoiner的单次toString()恢复机制。当一个StringJoiner被连续调用多次toString()并继续add时，功能是正常的，但如果有人在toString返回的字符串上再做修改，不会影响StringJoiner内部。这符合预期，但容易被人误以为StringJoiner和StringBuilder一样可以通过toString后的字符串反推内部状态。

第六类误用：在并发环境中使用静态的StringBuilder实例做公共缓冲区。这是非常危险的做法，相当于无锁共享一个可变全局状态，任何两个线程的append都可能互相覆盖。正确做法是每次线程内各自创建StringBuilder，或者放入ThreadLocal中。

用StringBuilder还是StringJoiner，取决于你需不需要分隔符和前后缀；用String还是用StringBuilder，取决于你是在处理不可变共享常量还是在做高频动态拼接。这三者不是替代关系，而是三个不同维度的工具。把每个工具的设计动机搞清楚，写代码时自然会选对，面试时也能从字符串本质的角度回答，而不是只背结论。

我在实际项目中总结出的一个习惯是：在写任何涉及字符串拼接的公共方法前，先花10秒问自己三个问题——这个字符串会被多个线程共享吗？我会在循环里反复追加吗？最终输出需要分隔符或前后缀格式吗？想清楚这三个问题，该用哪个类基本不需要犹豫。字符串相关的坑大多不是API不会用，而是没有把"对象创建频率"和"内存分配位置"这两件事放在心上。