Java 字符串操作：StringBuilder 与 StringBuffer 的区别

String 对象在 Java 中是不可变的，每次拼接都会在内存中生成全新对象。面对频繁修改场景，系统会自动堆积大量废弃数据。StringBuilder 与 StringBuffer 是官方提供的可变字符串容器。两者底层存储逻辑完全相同，核心差异集中在线程安全与执行速度上。

1. 定位核心差异

理解底层运行机制，是正确选型的前提。

1. 检查 线程同步机制。StringBuffer 的所有公开方法（如 append、delete、reverse）均使用 synchronized 关键字修饰。该机制相当于给方法加锁，确保同一时刻仅有一个线程能执行修改操作，防止数据错乱。StringBuilder 完全未加锁，多线程并发写入时可能抛出数组越界异常或产生脏数据。
2. 评估 性能损耗。加锁机制必然带来线程上下文切换与状态等待开销。在单线程环境下，StringBuilder 的执行速度通常比 StringBuffer 快 15% 至 25%，且 CPU 指令调度更直接。
3. 核对 版本兼容性。StringBuffer 随 JDK 1.0 发布，属于基础 API。StringBuilder 随 JDK 1.5 引入，专为无锁单线程环境优化。两者提供的方法名称与参数签名完全一致，互换只需替换类名。

2. 编写测试代码验证差异

通过实际编码对比执行效率与并发表现。

1. 创建 测试文件。在项目中建立 StringBenchmark.java。

2. 编写 单线程性能对比逻辑。

   public class StringBenchmark {
    public static void main(String[] args) {
        int loopCount = 5000000;
   
        // 测试 StringBuilder
        long start1 = System.currentTimeMillis();
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < loopCount; i++) {
            sb.append("Data");
        }
        long end1 = System.currentTimeMillis();
        System.out.println("StringBuilder 耗时: " + (end1 - start1) + " ms");
    }
   }

3. 复制 上方代码块，替换 StringBuilder 为 StringBuffer。

4. 运行 程序并 记录 控制台打印的耗时数值。无锁版本的执行时间将显著更低。

5. 验证 多线程安全性。构建并发测试环境：

   
   import java.util.concurrent.ExecutorService;
   import java.util.concurrent.Executors;

public class ThreadSafetyCheck {
public static void main(String[] args) throws InterruptedException {
final StringBuffer safeBuffer = new StringBuffer();
final StringBuilder unsafeBuilder = new StringBuilder();

    ExecutorService pool = Executors.newFixedThreadPool(8);

    for (int i = 0; i < 1000; i++) {
        pool.execute(() -> {
            for (int j = 0; j < 100; j++) {
                safeBuffer.append("X");
                unsafeBuilder.append("X"); // 此处存在并发竞争风险
            }
        });
    }
    pool.shutdown();
    pool.awaitTermination(3, java.util.concurrent.TimeUnit.SECONDS);

    System.out.println("Buffer 实际长度: " + safeBuffer.length());
    System.out.println("Builder 实际长度: " + unsafeBuilder.length());
}

}

6. **对比** 终端输出。`safeBuffer` 长度始终为 `100000`。`unsafeBuilder` 长度通常小于 `100000`，且可能直接中断报错。

---

## 3. 制定项目选型策略

根据业务场景严格匹配对应组件，避免性能浪费或线程灾难。

1. **识别** 运行上下文。确认当前代码是否被多个线程同时调用。若对象仅在方法栈局部作用域内流转（如独立工具方法、循环内部），**强制使用** `StringBuilder`。
2. **评估** 共享状态。若字符串容器作为类的静态成员变量或全局单例属性，且会被并发请求读写，**强制使用** `StringBuffer`。
3. **检查** 框架内置逻辑。主流日志组件与 Web 框架底层已接管线程调度。在业务层动态组装日志模板或 SQL 片段时，**优先选用** `StringBuilder`，无需重复加锁。
4. **替换** 历史遗留代码。维护 `JDK 1.4` 及以下老系统需保留原类。升级至 `JDK 1.5+` 且确认无跨线程共享后，直接执行全局检索替换，将类名统一改为 `StringBuilder`。

参考以下对照表快速决策：

| 判定维度 | `StringBuilder` | `StringBuffer` |
| :--- | :--- | :--- |
| 线程同步 | 无同步锁，非线程安全 | 内置 `synchronized` 锁，线程安全 |
| 执行效率 | 极高，零锁开销 | 中等，锁竞争消耗 CPU 周期 |
| 内存开销 | 仅保留字符数组与游标 | 额外分配监视器锁状态资源 |
| 典型场景 | 局部方法拼接、SQL 动态生成、单线程批处理 | 全局共享变量聚合、多线程协作写入、旧版兼容维护 |
| 最低版本 | `JDK 1.5` | `JDK 1.0` |

---

## 4. 执行最佳实践操作

掌握底层容量控制与复用技巧，进一步压榨性能。

1. **初始化** 预估容量。默认构造器仅分配 `16` 个字符空间。拼接长文本时，容量不足会触发底层数组扩容（计算公式为 `旧容量 * 2 + 2`），引发内存拷贝。在实例化时直接传入预期长度：`new StringBuilder(512)`。
2. **使用** 链式调用语法。两者方法均返回自身引用。将多个 `.append()` 串联在单行执行：`sb.append("ID:").append(userId).append("-Status:").append(code);` 减少临时变量声明。
3. **释放** 冗余空间。长生命周期容器完成拼接任务后，调用 `.trimToSize()` 方法。该操作会裁剪底层字符数组至实际使用长度，立即归还多余堆内存。
4. **清理** 循环复用对象。若容器需在 `while` 或 `for` 循环中反复使用，避免重复 `new`。在循环末尾调用 `.setLength(0)` **清空** 内容。复用已分配的底层数组，大幅降低垃圾回收频率。
5. **规避** 隐式拼接陷阱。在循环中编写 `str += item` 时，编译器会在字节码层自动创建临时拼接器。循环次数极高时，此行为仍会制造对象洪流。主动使用显式 `StringBuilder` 管理循环拼接，**阻断** 编译器自动生成的冗余指令。

严格遵循“单线程局部选 `StringBuilder`，多线程共享选 `StringBuffer`”原则。初始化时精确设定容量。循环复用调用 `.setLength(0)`。按此规范实施编码，即可彻底消除字符串操作的性能瓶颈与并发隐患。