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

原文来自于：zha-ge.cn/java/29

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

初遇字符串拼接的噩梦

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

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

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

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

揭开 String 的秘密面纱

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

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

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

StringBuilder 的华丽登场

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

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 闪亮登场了：

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

三兄弟的特性对比

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

使用场景的智慧选择

String：静态字符串的王者

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

StringBuilder：单线程性能之王

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

StringBuffer：多线程的守护者

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

经验启示

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

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

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

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

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