Java字符串处理：String、StringBuffer与StringBuilder深度解析

1. 为什么Java需要三种字符串处理类

在Java开发中，String、StringBuffer和StringBuilder这三个类的关系就像厨房里的不同刀具——虽然都能切菜，但各有专精。理解它们的本质区别，能帮助我们在实际开发中做出更合理的选择。

先看一个真实案例：某电商平台在促销活动时，系统突然出现卡顿。经排查发现，开发人员在生成商品详情页HTML时，使用了String进行大量字符串拼接，导致频繁创建对象和垃圾回收。当QPS达到5000+时，直接拖垮了JVM性能。后来改用StringBuilder重构后，CPU使用率下降了60%。

1.1 不可变性的设计哲学

String的不可变性（immutable）是Java语言设计的精妙之处。当我们写下String s = "hello"时：

1. JVM首先检查字符串常量池
   2.若不存在"hello"则创建并放入池中
   3.变量s指向该常量

这种设计带来三个关键优势：

• 安全性：作为HashMap的key时，不用担心被意外修改
• 线程安全：多线程环境下无需同步即可共享
• 性能优化：哈希值缓存、字符串常量池等机制得以实现

但不可变性也带来代价。看这段代码：

java复制String result = "";
for(int i=0; i<10000; i++){
    result += i; // 每次循环都new新对象
}

实际会产生10000个中间String对象，这在日志拼接、SQL生成等场景是性能杀手。

1.2 可变字符串的诞生背景

StringBuffer早在Java 1.0就存在，它的核心改进是：

1. 内部维护char[]数组，可动态扩容
2. 修改操作（append/insert等）直接改变数组内容
3. 所有公开方法都加了synchronized锁

这在早期多线程Web应用中很实用，比如Servlet时代响应内容拼接。但随着单线程场景增多，锁带来的性能损耗变得明显。

Java 1.5引入的StringBuilder，可以看作StringBuffer的"无锁版"。二者API完全兼容，但去掉了synchronized修饰。实测在单线程下，StringBuilder的性能比StringBuffer高出15%-30%。

2. 底层实现深度解析

2.1 String的存储机制

String的不可变秘密藏在源码里：

java复制public final class String {
    private final char value[];
    private int hash; // 缓存哈希值
}

这个final的char数组一旦初始化就不可变。所有看似"修改"的操作，实际都创建了新对象：

java复制String str = "飞";
str += "鸟"; // 实际是 new StringBuilder().append("飞").append("鸟").toString()
`