JVM StringTable与intern()机制深度解析：从编译优化到性能调优

JVM 调优绕不开 StringTable，尤其是准备 jvm 面试题的人，十有八九会被 intern() 和“字符串到底创建了几个对象”这类问题难住。我自己当年第一次看到 new String("java") + new String("java") 这种题目时，也是一脸懵，后来把 class 文件常量池、字节码指令、JVM 内存模型、GC 回收这几块全部串起来，才真正形成体系。StringTable 名字听起来只是一张表，但它横跨编译期、类加载期、运行期，背后还牵扯到对象创建、引用传递、内存分布和性能调优，绝不是一个可以“死记结论”的知识点。

这篇文章我打算从底层编译优化入手，先拆清楚字符串字面量从 class 文件到 StringTable 的完整路径，再深入 intern() 的核心机制，最后用几道高频面试题和实际参数调优来验证每个结论。无论你是准备 JVM 面试，还是想解决线上大量字符串导致的内存压力，这篇都可以给你一条完整可复用的分析思路。

1. StringTable 到底是个什么“表”

1.1 在 JVM 内存模型中的位置

很多人会混淆方法区、运行时常量池、字符串常量池这三者的关系。JVM 内存模型里，方法区存储类信息、常量、静态变量等数据，它是一种逻辑概念。在 JDK 6 及之前，方法区的实现是永久代（PermGen），StringTable 就躺在永久代里；JDK 7 开始，HotSpot 把 StringTable 挪到了 Java 堆；JDK 8 彻底移除永久代、引入元空间，但 StringTable 依然在堆中。

这个位置变化非常关键。永久代有固定大小限制，字符串一多就容易 OutOfMemoryError: PermGen space，而且永久代的垃圾回收条件很苛刻，字符串常量很难及时释放。搬进 Java 堆之后，StringTable 里的字符串对象可以像普通对象一样被 Young GC、Full GC 扫描和回收，内存瓶颈从“永久代不够用”变成了“堆不够用”，OOM 提示也变成了 Java heap space。

如果你去问一个准备 jvm 面试的人，StringTable 在哪，他能答出“JDK7 之前永久代、JDK7 之后堆”已经算不错。但更准确的理解是：StringTable 是一张由 JVM 内部 C++ 代码实现的哈希表，不属于任何 Java 标准库结构，你也无法通过标准 API 拿到它的直接引用。它只是 JVM 运行时维护的一张全局表，负责管理被“驻留”（intern）的字符串引用。

1.2 表里存的是引用，不是字符串内容

StringTable 的每个条目本质上是一个指向 String 对象的引用。String 对象本身在堆中分配，对象内部通过 char[]（JDK 8 及以前）或 byte[]（JDK 9 及以后）保存真正的字符内容。StringTable 利用字符串对象的哈希值作为 key 来计算桶位置，桶内再通过链表解决哈希冲突。

这个设计带来的一个直接收益是：如果多个变量引用同一个 String 对象，它们可以共享同一份底层字节数组，节省内存。intern() 的核心目的就是让这种情况更容易发生——尽量让相同内容的字符串在 JVM 里只有一份对象。

这里有一个常见的认识误区：有人以为 StringTable 里存的是字符串内容的字符数组，所以做 intern() 就能让所有字符串共享同一个数组。实际上不是。StringTable 存的是 String 对象引用，去重粒度是整个 String 对象，而不是内部数组。真正“共享底层数组”的优化是 JDK 9+ 的 Compact Strings 和 G1 的字符串去重，它们和 StringTable 是两套机制，后面我会单独讲。

2. 编译优化：class 文件里的字符串如何被加载

2.1 常量池里的 CONSTANT_Utf8 与 CONSTANT_String

在 Java 源码里写下一个字符串字面量，比如 "hello"，编译器会把这个字符串相关信息写进 class 文件的常量池。javap -v 可以看得一清二楚：

txt复制Constant pool:
   #7 = String             #8
   #8 = Utf8               hello

#7 是 CONSTANT_String_info，它并不直接保存字符串内容，而是指向 #8 这个 CONSTANT_Utf8_info 条目。CONSTANT_Utf8_info 里保存的是字符串实际内容的 UTF-8 编码字节。为什么要绕一层？因为 CONSTANT_String 表示“这是一个字符串常量”，而 CONSTANT_Utf8 还可能在符号引用、方法名等地方被复用，两者解耦更灵活。

但 class 文件里有了这个常量，并不代表 JVM 启动后马上就会创建对应的 String 对象。HotSpot 的常量池解析通常是惰性的，第一次执行到真正使用这个常量的字节码指令时，JVM 才会去创建 String 对象，并把它尝试放入 StringTable。这个细节能解释很多面试题，比如“为什么类加载完字符串没有立即进入常量池”之类的问题。

2.2 ldc 指令与 new String()：两条完全不同的路径

看下面这段代码：

java复制String s1 = "hello";
String s2 = new String("hello");

用 javap -c 看字节码：

txt复制 0: ldc           #7    // String hello
 2: astore_1
 3: new           #9    // class java/lang/String
 6: dup
 7: ldc           #7    // String hello
 9: invokespecial #11   // Method java/lang/String."<init>":(Ljava/lang/String;)V
12: astore_2

第一行 ldc #7 是处理字符串字面量的核心指令。ldc 会从常量池加载一个常量并压入操作数栈。当这个常量是 String 类型时，HotSpot 会确保 StringTable 中已经有相同内容的字符串；如果没有，就创建新的 String 对象并加入 StringTable，然后返回这个驻留后的引用。所以 s1 拿到的是 StringTable 中的那个“规范引用”。

再看第二段字节码，new 是真正在堆上分配一块内存，dup 复制栈顶引用，ldc #7 加载常量池中的字符串作为构造参数，最后 invokespecial 调用 String 的构造函数。new String("hello") 即使传入了常量池中的 "hello"，也会在堆上额外创建一个全新的 String 对象。

所以 s1 == s2 是 false，因为两者不是同一个对象；s1.equals(s2) 是 true，因为内容相同。这也是 JDK 文档里一直强调“应该用 equals() 比较字符串内容，而不是 ==”的最根本原因。

2.3 字符串拼接的编译优化：常量折叠与 StringBuilder

字符串拼接又分两种情况。

第一种，编译期能确定最终结果的拼接，比如：

java复制String a = "ja" + "va";
String b = "java";
System.out.println(a == b); // true

javac 在编译时会做常量折叠，"ja" + "va" 直接变成 "java"，生成的字节码就一条 ldc #xx。所以 a 和 b 都指向 StringTable 里同一个 "java" 对象。

第二种，拼接表达式里有变量，编译期算不出来，比如：

java复制String c = "ja";
String d = c + "va";

JDK 8 及之前，javac 会把它编译成类似这样的逻辑：

java复制StringBuilder sb = new StringBuilder();
sb.append(c);
sb.append("va");
String d = sb.toString();

StringBuilder.toString() 底层调用的是 new String(char[], ...)，创建出来的是一个全新的堆上对象，不会自动放入 StringTable。因此 d == "java" 是 false。如果你要让它和常量池里的 "java" 相等，必须手动 d.intern()。

JDK 9 之后，字符串拼接底层改成了 invokedynamic + StringConcatFactory，不再固定生成 StringBuilder 代码，但结论没变：运行时产生的拼接结果是一个新 String 对象，不会自动驻留。

这里要额外提醒一句：如果循环内用 += 拼接字符串，即使编译器每次都生成 StringBuilder，它也是在循环体内创建的新对象，无法复用。比如：

java复制String result = "";
for (int i = 0; i < 10000; i++) {
    result += String.valueOf(i);
}

每次迭代都会 new 一个 StringBuilder，最终产生大量中间对象，GC 压力很大。正确做法是循环外自己建一个 StringBuilder，手动 append。这和 StringTable 无关，但也是编译优化里的一个常见坑。

3. intern 机制深度解密

3.1 intern() 到底做了什么

先看官方语义：intern() 是 String 的 native 方法，调用时如果 StringTable 中已经有一个 equals 相等的字符串，就返回那个已存在字符串的引用；如果没有，则把当前 String 对象注册进 StringTable，并返回当前对象引用。

重点关注“如果没有，则把当前 String 对象注册进表”这句话。在 JDK 7 之后的 HotSpot 实现里，这个注册动作不是复制一份字符串内容到别的区域，而是直接把当前对象的引用放进 StringTable。也就是说，调用 s.intern() 成功后，s == s.intern() 可能为 true。

但在 JDK 6 时代不是这样。JDK 6 的 intern 会在永久代里复制出一个新的 String 对象，然后把这个副本放进 StringTable，原来堆里的 String 对象保持不变。正因为有这个复制动作，JDK 6 下 s.intern() == s 几乎总是 false。

3.2 JDK 6 与 JDK 7/8 的关键差异

可以用一张表总结：

这也是为什么同样是 intern() 相关代码，在不同 JDK 版本下结果完全不同的原因。如果你在面试题里看到“JDK 6 下结果如何”这种提问，本质就是在考察对 JVM 内存区域变化的理解。

另外 JDK 8 之后字符串对象内部存储从 char[] 改成了 byte[]，配合 Compact Strings，多数场景下更省内存。但这个变化不影响 intern 的语义，只影响底层内容存储。

3.3 StringTable 的哈希结构与性能

HotSpot 的 StringTable 本质是一个哈希表，每个桶后面挂一个链表，默认桶数量是 60013。可以用启动参数 -XX:StringTableSize 修改。JVM 计算字符串的哈希值后模上桶数定位，然后在该桶链条上逐一比较；遇到哈希碰撞会退化为线性比较，所以如果字符串条目数量远大于桶数，查找性能会明显下降。

字符串一旦 intern 成功，就被 StringTable 强引用住，无法被 GC 回收，除非 StringTable 自身发生重哈希或者条目被显式移除。实际上 HotSpot 的字符串表条目只有在 GC 清理不活跃的 intern 字符串时才会考虑移除，但开发者通常不能依赖这种行为。这个特性也决定了 intern() 在大规模动态字符串场景下可能成为内存黑洞。

4. 高频 JVM 面试题与实例验证

4.1 new String("a") 到底创建了几个对象

经典题，先给结论，分两种情况：

假设执行这段代码前，StringTable 里还没有 "a"：

java复制String s = new String("a");

这里一共有 2 个字符串对象：第一个是在执行 ldc #7 时创建并放入 StringTable 的 "a" 常量对象；第二个是 new 在堆上创建的新的 String 对象。s 指向的是后面这个新对象。

如果 JVM 启动后已经有其他地方加载过字面量 "a"，那么这里只会新增 1 个对象，即 new 出来的堆对象。

可以把代码放到本地跑一遍验证：

java复制public class StringDemo {
    public static void main(String[] args) {
        String s = new String("a");
        System.out.println(s.intern() == s); // 首次驻留时 true
    }
}

如果只执行这个方法且没有提前加载 "a"，s.intern() 会把 s 自己放入 StringTable，所以返回引用就是 s，s.intern() == s 为 true。

4.2 经典的 intern 与拼接组合题

高频题长这样：

java复制String s = new String("a") + new String("b");
String t = s.intern();
String u = "ab";
System.out.println(s == t); // ?
System.out.println(t == u); // ?

先明确一个前提："a" 和 "b" 都是字面量，加载后会在 StringTable 中各自占一条；但拼接结果 "ab" 在 StringTable 中从来没有出现过。

执行 new String("a") + new String("b") 时，javac 会生成 StringBuilder 拼接逻辑，最终 s 指向一个新创建的 "ab" 对象。此时调用 s.intern()，因为 StringTable 里没有 "ab"，JDK 7+ 会直接把 s 对象引用放入 StringTable 并返回它，所以 s == t 是 true。

接着 String u = "ab"，执行 ldc 时发现 StringTable 已经有 "ab"，于是 u 也指向同一个对象，所以 t == u 也是 true。

但换个场景，如果在执行这段代码之前，StringTable 已经被别的代码放入过 "ab"，那么 s.intern() 返回的是之前那个已存在的引用，s == t 就是 false。这也是最容易踩坑的地方：intern 的结果严重依赖运行时的状态，不是恒定不变的。

如果把同样的代码放到 JDK 6 下，s.intern() 会先在永久代复制一个 "ab" 副本再返回，s == t 永远是 false。所以这种题面试官一定会追问“JDK 版本是多少”。

4.3 用命令验证 StringTable 的规模与统计

JDK 内置了命令可以查看 StringTable 的统计信息。比如使用 jcmd：

bash复制jcmd <pid> VM.stringtable

输出通常包含桶数量、条目数量、平均桶长等信息。也可以通过启动参数在程序退出时打印：

bash复制java -XX:+PrintStringTableStatistics StringDemo

大致会看到类似这样的内容：

txt复制StringTable statistics:
Number of buckets       :     60013
Average bucket size     :     1.002
Variance of bucket size :     0.001

如果条目数远大于桶数，平均桶长会明显上升，说明哈希冲突严重，此时可以考虑调大 -XX:StringTableSize。建议所有准备做 JVM 调优的人，先学会看这个统计，再决定要不要动参数。

5. 性能陷阱与调优建议

5.1 intern 是内存救星，但不是万能药

很多人听说 intern() 可以省内存，就想着把所有字符串都 intern() 一下。这其实很危险。它确实有收益，但代价也很清晰：

• StringTable 是全局共享结构，早期版本底层有锁，并发频繁调用 intern 可能造成线程争用。
• intern 后的字符串会被 StringTable 强引用，相当于“常驻”，回收难度变大。
• 如果 intern 的是大量不重复的动态字符串，比如日志内容、随机订单号、带时间戳的拼接结果，表会迅速膨胀，哈希冲突和内存占用同时飙升。

适合 intern 的场景是：字符串取值集合有限、重复率特别高，比如状态枚举、国家代码、数据库列名、业务字典类型。不适合的场景是：每次都不一样的高基数字符串。

5.2 -XX:StringTableSize 的正确调整姿势

如果 StringTable 统计显示条目已经几十万甚至上百万，默认的 60013 个桶显然不够。把桶数调大能降低冲突，让查找和插入更快。启动命令示例：

bash复制java -XX:StringTableSize=200000 -Xmx2g -jar app.jar

但不要拍脑袋设一个超大值。桶数越大，JVM 初始化的哈希表内存占用越高，如果程序实际根本没那么字符串，纯属浪费。另外 JVM 参数必须在启动时生效，运行期改不了。调完后可以用 jcmd VM.stringtable 再对比一次平均桶长，确认是否真的有效。

一个保守的做法是：先跑一段时间压测，观察 VM.stringtable 输出的条目数量，然后把 -XX:StringTableSize 设置成略大于条目数的 1.2 到 1.5 倍，留出增长空间。这比网上流传的“直接设个 100 万”靠谱得多。

5.3 现代 JVM 的字符串去重与 intern 的区别

JDK 8u20 之后，G1 垃圾收集器支持字符串去重，通过 -XX:+UseStringDeduplication 开启。它的原理是让多个 String 对象内部共享同一个 char[] 或 byte[] 数组，从而减少重复的内容存储。注意，String 对象本身还是多个，引用相等性依然是 false，只是内容存储被压缩了。

StringTable 的 intern 则是让多个引用指向同一个 String 对象，对象级别去重。两者的内存优化逻辑不同，适用场景也不同。如果你只是为了省内存，不关心 == 引用相等，优先考虑 G1 字符串去重或 Compact Strings；如果你确实需要保证某些字符串在全局只有一份，才该考虑 intern。把这两套机制分开，线上调优才不会打架。

5.4 常见问题与排查思路

遇到字符串相关的内存异常，我一般按这四个步骤排查：

1. 先看 StringTable 统计：jcmd <pid> VM.stringtable，确认条目数是否异常。如果条目数几十万级但桶只有 60013，先考虑调参。
2. 再用 jmap -histo:live <pid> | head -20 看 java.lang.String 和 char[]/byte[] 实例数量。注意 char[]/byte[] 数量多不一定代表字符串对象多，也可能是普通数组。
3. 检查代码里有没有对动态值调用 intern()。如果有，重点看这些值是否高基数、是否长期存活。
4. 如果用的是 G1，并开启了字符串去重，可以观察 GC 日志里的去重统计，确认收益是否达到预期。

我曾经在一个项目里见过非常典型的案例：接口层为了“省内存”，把每个入参里的用户昵称都 intern() 了一下，结果用户昵称数量几十万，每个只出现几次，StringTable 被塞满，老年代不断涨，最后触发频繁 Full GC。把 intern() 去掉后，内存立刻恢复平稳。从那之后我对 intern 的告诫就一句话：对固定集合内的值去重，别对流水号去重。

StringTable 的知识点看起来零散，实际都是围绕“对象引用何时相等”展开的。JDK 版本变了，内存分布变了，编译优化变了，但核心思想没有变：字符串字面量倾向驻留，运行期构造的字符串默认不驻留，intern() 是用来人工打破这条边界的手段。多写几行 javap 验证一下，再结合线上统计调整参数，比死记任何结论都有用。