Java String vs StringBuilder vs StringBuffer：一个性能优化的探险故事

初遇字符串拼接的噩梦

那是一个阳光明媚的周二下午，我正在为公司的日志系统写一个数据处理模块。需求很简单：把几千条用户操作记录拼接成一个大字符串，然后写入文件。

我满怀信心地写下了这样的代码：

java 复制代码

String result = "";
for (LogRecord record : logRecords) {
    result += record.getTimestamp() + " | " + record.getUserId() + " | " + record.getAction();
    // ... 其他字段拼接
}

测试时发现，当数据量达到 1 万条时，程序居然跑了 30 多秒！我的第一反应是："这不科学啊，就是个字符串拼接而已。"

揭开 String 的秘密面纱

经过一番调研，我才恍然大悟。原来 Java 中的 String 就像是一个"顽固的老头"------不可变 （Immutable）。每次看似简单的 += 操作，实际上都会：

创建一个新的 String 对象
把原来的内容复制过去
加上新的内容
抛弃旧对象

想象一下，1 万次循环就是 1 万次"搬家"，难怪这么慢！

StringBuilder 的华丽登场

同事小李看到我愁眉苦脸的样子，神秘一笑："兄弟，试试 StringBuilder 吧。"

java 复制代码

StringBuilder sb = new StringBuilder();
for (LogRecord record : logRecords) {
    sb.append(record.getTimestamp())
      .append(" | ")
      .append(record.getUserId())
      .append(" | ")
      .append(record.getAction());
}
String result = sb.toString();

这次测试结果让我惊呆了------同样的 1 万条数据，只用了不到 1 秒！

StringBuilder 就像一个"可扩展的购物袋"，内部维护一个字符数组。当空间不够时，它会自动扩容，而不是每次都换个新袋子。

踩坑瞬间：线程安全的陷阱

正当我为找到神器而沾沾自喜时，生产环境出现了奇怪的问题：偶尔会出现字符串内容错乱。经过排查发现，多个线程在并发操作同一个 StringBuilder 实例！

原来 StringBuilder 是线程不安全的。在多线程环境下，它就像是几个人同时往一个袋子里塞东西，结果可想而知。

这时候，StringBuffer 闪亮登场了：

java 复制代码

StringBuffer buffer = new StringBuffer();
// 在多线程环境下安全使用
buffer.append("线程安全的字符串拼接");

三兄弟的特性对比

经过这次"血泪教训"，我总结了三者的核心特点：

特性	String	StringBuilder	StringBuffer
可变性	不可变	可变	可变
线程安全	安全	不安全	安全
性能	最慢	最快	中等
内存开销	大	小	小

使用场景的智慧选择

String：静态字符串的王者

字符串内容不会改变
少量字符串操作
作为方法参数传递

StringBuilder：单线程性能之王

大量字符串拼接操作
单线程环境
对性能要求较高的场景

StringBuffer：多线程的守护者

多线程环境下的字符串操作
需要保证线程安全
可以接受略微的性能损失

经验启示

这次探险让我明白了几个道理：

没有银弹：每种工具都有其适用场景，关键是理解其特性
性能测试很重要：看似简单的操作可能隐藏着巨大的性能陷阱
多线程环境要格外小心：线程安全不是可有可无的"装饰品"

现在，当新同事问我字符串拼接用什么时，我总是会问："单线程还是多线程？性能要求高吗？"

毕竟，选择合适的工具，就像给脚穿合适的鞋------只有合脚，才能走得更远。

小贴士：在现代 Java 版本中，编译器会自动将简单的字符串拼接优化为 StringBuilder，但复杂场景下，手动选择仍然是最佳实践。