1. 为什么需要深入理解String源码
作为Java开发者，我们几乎每天都在与String打交道。但你是否遇到过这样的困惑：为什么两个看似相同的字符串用==比较返回false？为什么String被设计为不可变类？String的substring方法在JDK不同版本中为何会有性能差异？这些问题的答案都藏在String源码的实现细节中。
我曾在一次性能调优中，发现一个简单的字符串拼接操作竟成为系统瓶颈，通过深入String源码才找到根本原因。理解String的底层实现不仅能帮助我们避免常见的坑，更能写出高效、健壮的代码。特别是在面试中，String相关问题是必考点，从内存模型到方法实现，面试官往往期待候选人有源码级别的理解。
2. String类的核心设计解析
2.1 不可变性的实现机制
打开String.java源码，首先映入眼帘的是这个类被final修饰，且所有字段都是private final的。这种设计确保了String实例一旦创建就不可修改。我们来看关键字段：
java复制private final char value[];
private final int offset; // JDK7后已移除
private final int count; // JDK7后已移除
private int hash; // 缓存哈希值
在JDK6及之前，String使用offset和count实现共享字符数组，但这种设计容易导致内存泄漏。从JDK7开始，String简化为直接持有char[]，不再共享数组。这种变化体现了Java团队对性能与安全的权衡。
重要提示：在JDK6中使用substring时，原字符串的char[]会被子字符串引用，即使原字符串不再使用，数组也无法被GC回收。这是为什么升级到JDK7+能解决某些内存问题的原因。
2.2 字符串常量池的运作原理
当我们写下String s = "hello"时，JVM会检查字符串常量池中是否已存在该字面量。如果存在则直接返回引用，否则在池中创建新对象。这个过程是通过StringTable实现的，它是一个固定大小的HashTable，默认大小在JDK8中是60013。
使用new String("hello")则会强制在堆中创建新对象，即使常量池中已有相同内容。这种差异解释了为什么以下代码会有不同结果：
java复制String a = "hello";
String b = "hello";
String c = new String("hello");
System.out.println(a == b); // true
System.out.println(a == c); // false
3. 关键方法源码剖析
3.1 equals方法的精妙实现
String的equals方法是我们最常用的方法之一，它的实现非常值得学习：
java复制public boolean equals(Object anObject) {
if (this == anObject) {
return true;
}
if (anObject instanceof String) {
String anotherString = (String)anObject;
int n = value.length;
if (n == anotherString.value.length) {
char v1[] = value;
char v2[] = anotherString.value;
int i = 0;
while (n-- != 0) {
if (v1[i] != v2[i])
return false;
i++;
}
return true;
}
}
return false;
}
这个方法展示了几个优化技巧：
- 先比较引用地址（快速路径）
- 再检查类型和长度
- 最后逐个字符比较
- 使用局部变量减少数组访问开销
3.2 hashCode的缓存策略
String的hashCode计算是一次性工作，结果会被缓存：
java复制public int hashCode() {
int h = hash;
if (h == 0 && value.length > 0) {
char val[] = value;
for (int i = 0; i < value.length; i++) {
h = 31 * h + val[i];
}
hash = h;
}
return h;
}
这里有几个设计亮点：
- 使用31作为乘数（素数减少哈希冲突）
- 延迟初始化hash字段
- 双重检查锁定模式（线程安全）
4. 性能优化实战技巧
4.1 字符串拼接的陷阱与优化
常见的字符串拼接有以下几种方式：
- 使用+运算符
- 使用StringBuilder
- 使用StringJoiner（JDK8+）
- 使用String.format
在循环中拼接字符串时，+运算符会创建大量临时对象。例如：
java复制// 反例 - 每次循环都会new StringBuilder
String result = "";
for (int i = 0; i < 100; i++) {
result += i;
}
// 正例 - 单一StringBuilder
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 100; i++) {
sb.append(i);
}
String result = sb.toString();
编译器会对简单的+拼接进行优化，但在复杂场景（如循环）中仍会产生性能问题。我在实际项目中曾通过将+改为StringBuilder，将某个接口的响应时间从200ms降到50ms。
4.2 intern方法的使用场景
String.intern()可以将字符串放入常量池，但滥用会导致性能下降。适合使用intern的场景：
- 大量重复字符串且需要频繁比较
- 字符串生命周期长
- 内存充足
不适合的场景：
- 短生命周期字符串
- 字符串变化多
- 内存紧张
我曾经在解析CSV文件时使用intern来规范化重复的枚举值，内存使用减少了30%，但需要谨慎监控常量表大小。
5. JDK版本演进中的重要变化
5.1 JDK9的紧凑字符串
JDK9引入了紧凑字符串(Compact Strings)特性，当字符串仅包含Latin-1字符时，使用byte[]而非char[]存储，节省约50%内存。这是通过新增的coder字段实现的：
java复制private final byte[] value;
private final byte coder; // 0 = Latin-1, 1 = UTF-16
这个改动对开发者透明，但解释了为什么JDK9后某些字符串操作性能有所变化。
5.2 JDK15的文本块
虽然不属于String源码变化，但文本块(Text Blocks)极大改善了多行字符串的可读性：
java复制// 传统方式
String html = "<html>\n" +
" <body>\n" +
" <p>Hello</p>\n" +
" </body>\n" +
"</html>\n";
// 文本块方式
String html = """
<html>
<body>
<p>Hello</p>
</body>
</html>
""";
编译器会将文本块转换为普通字符串，运行时没有额外开销。
6. 常见面试题深度解析
6.1 String为什么设计为不可变
这个问题考察对String设计的理解，可以从以下几个角度回答：
- 安全性：字符串常用于敏感信息（如密码），不可变防止被篡改
- 线程安全：天然线程安全，无需同步
- 缓存哈希：可以安全缓存hashCode
- 常量池优化：实现字符串复用
- 类加载机制：类名等字符串需要稳定
6.2 String、StringBuilder和StringBuffer的区别
这个问题几乎必考，可以从这几个维度对比：
| 特性 | String | StringBuilder | StringBuffer |
|---|---|---|---|
| 可变性 | 不可变 | 可变 | 可变 |
| 线程安全 | 是（天然） | 否 | 是 |
| 性能 | 低（拼接时） | 高 | 中等 |
| 使用场景 | 常量字符串 | 单线程字符串操作 | 多线程字符串操作 |
6.3 如何比较两个字符串是否相等
这个问题看似简单，但能区分新手和老手：
- 使用equals()而非==比较内容
- 注意null检查：str != null && str.equals("text") 或 "text".equals(str)
- 需要忽略大小写时使用equalsIgnoreCase()
- 对于已知非null的字符串，可以直接用字面量.equals(str)避免NPE
7. 实际开发中的经验分享
7.1 字符串编码问题排查
在处理IO或网络传输时，经常会遇到编码问题。我的排查步骤通常是：
- 确认数据源编码（如HTTP头、文件元数据）
- 检查JVM默认编码（file.encoding系统属性）
- 显式指定编码：new String(bytes, "UTF-8")
- 使用StandardCharsets类避免拼写错误
一个常见错误是混淆编码名称，比如"UTF8"应该是"UTF-8"。我习惯使用StandardCharsets常量：
java复制// 推荐
new String(bytes, StandardCharsets.UTF_8);
// 不推荐
new String(bytes, "UTF-8");
7.2 大字符串处理技巧
处理大字符串（如XML/JSON）时需要注意：
- 避免将整个文件读入内存，使用流式处理
- 使用StringBuilder的合适初始容量（默认16可能太小）
- 考虑使用CharBuffer等NIO类
- 对于正则表达式，注意贪婪匹配可能导致性能问题
我曾经优化过一个日志分析工具，通过调整StringBuilder初始容量从默认16到预期大小的2倍，性能提升了40%。