String, StringBuilder 和 StringBuffer 的区别与使用场景-java教程-PHP中文网

答案：String不可变，线程安全，适合少量拼接；StringBuilder可变，非线程安全，单线程大量拼接性能最佳；StringBuffer可变，线程安全，多线程适用但性能较低。

string, stringbuilder 和 stringbuffer 的区别与使用场景

在Java的世界里，处理字符串是日常到不能再日常的任务，而String、StringBuilder和StringBuffer这三兄弟，初看起来都像是用来装文字的容器，但它们骨子里的脾气秉性却大相径庭，直接影响着我们代码的性能和线程安全。简单来说，String是不可变的，一旦创建就无法更改，任何看起来像修改的操作，实际上都是创建了一个新的String对象；StringBuilder是可变的，非线程安全，在单线程环境下进行大量字符串拼接时性能最佳；而StringBuffer也是可变的，但它是线程安全的，适合多线程并发操作，不过因此会牺牲一些性能。

解决方案

理解String、StringBuilder和StringBuffer的核心差异，在于把握它们的“可变性”和“线程安全性”。

String：不变的承诺 String对象在Java中是不可变的（Immutable）。这意味着，当你声明

String s = "hello";

登录后复制

后，这个"hello"字符串在内存中的内容就固定了。如果接着执行

s = s + " world";

登录后复制

，JVM并不是在原有的"hello"后面追加" world"，而是先创建了一个新的字符串"hello world"，然后将s的引用指向这个新对象。原来的"hello"对象如果没有其他引用，就会等待垃圾回收。这种不可变性带来了一些好处：

线程安全： 多个线程可以安全地共享同一个String对象，因为它们无法修改它，也就不会引发数据不一致的问题。
安全性： String常用于存储敏感信息，如密码。不可变性确保了这些信息在创建后不会被意外修改。
哈希码缓存： String的哈希码在第一次计算后会被缓存，因为内容不会变，所以可以一直使用，这在HashMap等数据结构中非常高效。但其缺点也很明显：频繁的字符串拼接操作会导致创建大量的临时String对象，这会消耗额外的内存和CPU资源，尤其是在循环中。

StringBuilder：高效的变脸大师（单线程） StringBuilder在Java 5中引入，是为了解决String在大量拼接操作时的性能问题。它与String最大的不同是“可变性”。当你使用StringBuilder进行拼接时，它会在内部维护一个可变的字符数组（或者说一个缓冲区），当容量不足时，会自动扩容。所有修改操作（如

append()

登录后复制

、

insert()

登录后复制

、

delete()

登录后复制

等）都是在原对象上进行的，不会创建新的对象。

性能优越： 在单线程环境下，进行大量字符串拼接时，StringBuilder的性能远超String。
非线程安全： 这也是它高性能的原因之一。它的方法没有进行同步（
```
synchronized
```
登录后复制
）处理，因此在多线程环境下，多个线程同时修改同一个StringBuilder对象可能会导致数据不一致。

StringBuffer：稳重的变脸大师（多线程） StringBuffer与StringBuilder非常相似，它也是可变的，并且提供了几乎相同的API。它们之间的核心区别在于“线程安全性”。StringBuffer的所有公共方法都是

synchronized

登录后复制

修饰的，这意味着在任何时刻，只有一个线程可以访问它的方法，从而保证了在多线程环境下的数据一致性。

线程安全： 适合在多线程环境下进行字符串操作。
性能开销： 由于同步机制的存在，StringBuffer的性能通常会比StringBuilder差一些，因为每次方法调用都需要获取和释放锁。

总结：

String： 不可变，线程安全，适用于字符串内容不变或少量拼接的场景。
StringBuilder： 可变，非线程安全，适用于单线程环境下大量字符串拼接的场景。
StringBuffer： 可变，线程安全，适用于多线程环境下大量字符串拼接的场景。

为什么Java要设计三种类似的字符串处理类？

这其实是Java在不同历史时期和不同需求背景下，对字符串处理能力的一种演进和细化。最初，Java只有

String

登录后复制

，它的不可变性是出于安全性和效率的考量，比如字符串池（String Pool）的实现就依赖于此。想象一下，如果字符串是可变的，那么一个引用改变了字符串内容，所有指向同一个字符串字面量的引用都会受到影响，这会引发混乱和安全漏洞。而且，作为Map的键或者Set的元素，不可变性保证了它们的哈希码和相等性判断的稳定性。

然而，随着应用程序变得越来越复杂，需要进行大量字符串拼接的场景越来越多，比如构建动态SQL语句、生成复杂的日志信息、组装HTTP请求体等。在这种情况下，如果每次拼接都生成一个新的String对象，内存开销和GC压力会迅速飙升，性能会变得非常糟糕。这就像你每次想在纸上多写几个字，不是直接在原稿上写，而是重新抄写一份完整的稿子，再把新字加上去，效率可想而知。

为了解决这个问题，Java在早期版本中引入了

StringBuffer

登录后复制

。它提供了可变字符串的能力，通过内部的字符数组进行操作，大大提升了拼接效率。同时，考虑到多线程并发修改字符串的场景，

StringBuffer

登录后复制

的所有方法都设计成了同步的（

synchronized

登录后复制

），确保了线程安全。这在当时是相当必要的，因为多线程编程已经开始普及。

但到了Java 5，随着对性能极致追求的呼声越来越高，开发者们发现，很多字符串拼接操作实际上都发生在单线程环境中。在这种情况下，

StringBuffer

登录后复制

的同步机制就成了一种不必要的开销。每次方法调用都进行加锁、释放锁，这会消耗CPU时间。于是，

StringBuilder

登录后复制

应运而生。它与

StringBuffer

登录后复制

功能几乎完全一致，但移除了所有的同步锁，从而在单线程环境下提供了更高的性能。

所以，这三种类的存在，并非冗余，而是Java语言设计者们在“安全性”、“性能”和“线程并发”这三者之间，根据不同的应用场景给出的最佳实践。它们共同构成了Java强大而灵活的字符串处理体系。

在实际开发中，我应该如何选择合适的字符串类？

选择合适的字符串类，是Java开发中一个很基础但又很重要的决策，它直接影响你代码的性能和健壮性。这里我分享一些我个人的经验和思考，希望能帮你做出明智的选择：

默认优先使用
```
String
```
登录后复制
- 理由： 如果你的字符串内容一旦创建就不会改变，或者只涉及少量、简单的拼接操作（比如只有一两次
```
+
```
  登录后复制
  操作），那么直接使用
```
String
```
  登录后复制
  是最好的选择。它的不可变性带来了简洁、安全、易于理解的代码，并且JVM对
```
String
```
  登录后复制
  的
```
+
```
  登录后复制
  操作在编译期通常会进行优化，将其转换为
```
StringBuilder
```
  登录后复制
  的
```
append
```
  登录后复制
  操作（Java 5及以后），所以少量拼接的性能损失并不明显。
- 示例场景： 定义常量字符串、方法参数、返回结果（如果内容固定）、Map的键等。
- 注意事项： 避免在循环中进行
```
String
```
  登录后复制
  的
```
+
```
  登录后复制
  操作，那会是性能的灾难。
单线程大量拼接，选择
```
StringBuilder
```
登录后复制
- 理由： 当你明确知道你的字符串操作（尤其是拼接）只发生在单个线程中，并且涉及大量的修改或拼接（比如在一个循环中迭代构建一个长字符串），那么
```
StringBuilder
```
  登录后复制
  是你的不二之选。它提供了最高的性能，因为它没有同步开销。
- 示例场景：
  - 从数据库查询结果中构建一个复杂的报告字符串。
  - 在一个循环中将多个用户输入拼接成一个日志条目。
  - 解析文件内容，逐步构建处理后的字符串。
- 代码示例：
```
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
    sb.append("Item ").append(i).append("\n");
}
String result = sb.toString();
```
  登录后复制
多线程并发操作，选择
```
StringBuffer
```
登录后复制
- 理由： 如果你的字符串操作需要在多个线程之间共享，并且这些线程会同时尝试修改这个字符串对象，那么
```
StringBuffer
```
  登录后复制
  是唯一安全的选项。它的内部同步机制会确保数据的一致性，避免竞态条件和不可预测的结果。
- 示例场景：
  - 多个线程同时向一个共享的日志缓冲区写入日志信息。
  - 在一个Web服务器中，多个请求线程需要并发地更新一个共享的统计字符串。
- 注意事项： 尽管
```
StringBuffer
```
  登录后复制
  是线程安全的，但在多线程环境中，如果你能通过其他方式（比如局部变量、ThreadLocal、或者更高级的并发工具）避免共享可变状态，那么优先考虑这些方案。因为
```
StringBuffer
```
  登录后复制
  的同步开销依然存在，如果并发度很高，可能会成为性能瓶颈。
  
  魔乐社区
  天翼云和华为联合打造的AI开发者社区，支持AI模型评测训练、全流程开发应用
  
  102
  
  查看详情
- 代码示例：
```
final StringBuffer sBuffer = new StringBuffer();
Runnable task = () -> {
    for (int i = 0; i < 100; i++) {
        sBuffer.append(Thread.currentThread().getName()).append(": ").append(i).append("\n");
    }
};

Thread t1 = new Thread(task, "Thread-1");
Thread t2 = new Thread(task, "Thread-2");
t1.start();
t2.start();

try {
    t1.join();
    t2.join();
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
}
System.out.println(sBuffer.length()); // 长度会是预期的 200 * (平均每个元素长度)
```
  登录后复制

总而言之，我的经验是：先考虑

String

登录后复制

，如果发现有性能瓶颈（大量拼接），再考虑

StringBuilder

登录后复制

。如果是在多线程环境且确实需要共享可变字符串，那么才考虑

StringBuffer

登录后复制

。很多时候，我们其实并不需要

StringBuffer

登录后复制

的线程安全特性，因为通过良好的设计，我们可以避免在多线程之间共享可变字符串，或者使用更细粒度的锁来优化。过度使用

StringBuffer

登录后复制

反而可能带来不必要的性能损耗。

String的不可变性具体带来了哪些好处和挑战？

String的不可变性是Java语言设计中一个非常核心的特性，它既是福也是祸，带来了显著的优势，也引入了一些需要我们巧妙应对的挑战。

不可变性的好处：

线程安全： 这是最直接的好处。由于String对象一旦创建就不能被修改，所以多个线程可以安全地共享同一个String实例，无需额外的同步措施。这大大简化了并发编程，避免了许多潜在的竞态条件和数据不一致问题。你可以放心地将String对象作为方法参数传递，或存储在共享数据结构中，而不必担心它会被其他线程意外修改。
安全性： 在许多安全敏感的场景中，例如存储密码、数据库连接字符串、文件路径等，String的不可变性至关重要。如果String是可变的，那么在应用程序的某个地方获取到密码字符串后，其他代码可能会意外或恶意地修改它，导致安全漏洞。不可变性保证了这些敏感信息在创建后不会被篡改，提高了系统的整体安全性。
字符串池（String Pool）的实现基础： Java的字符串池是一种优化机制，它将常用的字符串字面量存储在内存的一个特殊区域。当创建新的字符串时，JVM会首先检查字符串池中是否已经存在相同内容的字符串。如果存在，就直接返回现有字符串的引用，而不是创建新对象。这种机制极大地节省了内存。而字符串池之所以能正常工作，正是因为String的不可变性：如果字符串是可变的，那么池中的字符串被修改后，所有引用它的地方都会受到影响，导致混乱。
哈希码的缓存： String类重写了
```
hashCode()
```
登录后复制
方法，并且由于其不可变性，String的哈希码在第一次计算后就会被缓存起来。后续再调用
```
hashCode()
```
登录后复制
时，直接返回缓存值，无需重新计算。这对于将String作为
```
HashMap
```
登录后复制
的键或
```
HashSet
```
登录后复制
的元素时，性能提升非常显著，因为这些数据结构频繁地依赖哈希码进行查找和存储。
用作Map的键： 正是由于其不可变性和哈希码的缓存，String非常适合作为
```
HashMap
```
登录后复制
和
```
Hashtable
```
登录后复制
的键。它确保了键的稳定性和一致性，一旦作为键放入Map中，其哈希码和相等性判断就不会改变，从而保证了Map的正常工作。

不可变性带来的挑战：

性能开销（大量拼接）： 这是最常被提及的挑战。当需要对字符串进行大量修改或拼接操作时，由于String的不可变性，每次操作都会创建一个新的String对象，并将旧对象标记为垃圾。这会导致频繁的对象创建和垃圾回收（GC），从而消耗大量的内存和CPU资源，显著降低程序性能。例如，在一个循环中用
```
+
```
登录后复制
操作符拼接一千个字符串，最终可能会创建数千个临时String对象。
内存占用： 频繁创建临时对象不仅影响性能，还会增加内存占用。尤其是在处理大数据量或长生命周期的应用中，大量的临时String对象可能导致内存溢出（OutOfMemoryError）或显著增加GC暂停时间。
API的局限性： String类本身提供的方法都是返回新的String对象，而不是修改自身。这使得在某些需要原地修改字符串的场景下，String的API显得不够灵活。例如，如果你想替换字符串中的某个字符，你不能直接修改，只能得到一个新的替换后的字符串。

为了应对这些挑战，Java引入了