如何通过 JVM 字节码指令 ldc 的常量池引用过程理解 Java 字符串常量池的底层寻址逻辑

在深入讨论JVM字节码指令ldc与字符串常量池的关系之前，先澄清一个核心概念：ldc指令本身并不直接操作StringTable，它加载的是运行时常量池中一个CONSTANT_String_info结构的索引。真正触发字符串驻留（也就是“进池”或“查池”）的，是后续的符号引用解析过程——这个过程可能发生在类初始化之前，也可能延迟到首次执行ldc指令时。

ldc 加载的是 CONSTANT_String_info，不是 String 对象

Ja va源码中的String s = "hello";，编译后字节码通常对应ldc #5。这里的#5指向class文件常量池中一个CONSTANT_String_info项——但它本身并不直接存储字符串内容，而是保存了另一个索引（比如#12），#12才是真正的CONSTANT_Utf8_info，里面是UTF-8编码的字节序列。

换句话说：ldc压栈的只是一个“待解析的符号引用”，既不是ja va.lang.String实例，更不是对StringTable的直接引用。

• 在解析之前，ldc对应的运行时常量池项类型是JVM_CONSTANT_UnresolvedString
• 首次执行该ldc指令时，JVM才会触发解析：先去StringTable中查找是否已有对应的字符串实例；如果没有，就在堆中新建一个，并将该实例引用存入StringTable
• 解析完成后，该项被替换为JVM_CONSTANT_String，后续再执行同一条ldc指令时，就直接返回已驻留的引用

为什么 new String("abc") 不走 ldc 解析流程

new String("abc") 对应的字节码，通常包含ldc #3（加载字面量）和invokespecial（调用构造器）两条指令。其中ldc确实会触发字符串驻留，但new操作本身强制在堆上创建新对象——这个行为与StringTable中是否已存在该字符串完全无关。

关键区别在于：是否“由ldc直接产生引用”。只有当字节码中某处ldc的结果被当作字符串值来使用——比如赋值给静态字段、作为方法参数传入、或者参与字符串拼接的编译期优化——才有可能让该字符串被驻留。而new构造出的对象，永远是一个新的堆对象，除非显式调用.intern()方法。

• ldc是“触发驻留”的常见入口，但并非唯一入口（String.intern()也能主动写入）
• ldc是否真的导致驻留，取决于它是否被用于生成字符串值——如果只是被丢弃或仅作类型检查，JVM可能会延迟甚至跳过解析（HotSpot有惰性解析策略）
• JDK 7+之后，StringTable位于堆中，因此ldc解析出的引用指向的是堆内对象，而非方法区或元空间

ldc 和 intern() 在常量池寻址上的本质差异

ldc是被动解析：按需、单向、不可控。而intern()是主动干预：无论来源，强制查表并写入（若不存在）。

举个例子：String s = new String("abc").intern();，其行为等价于先执行ldc #x（驻留"abc"），再执行new（建新对象），最后调用intern()返回已驻留的引用。但如果"abc"已经由其他ldc指令驻留过，那么intern()就直接返回那个已有的引用。

• ldc的路径是：运行时常量池 → 触发解析 → 查StringTable → 写入（若不存在）
• intern()则绕过常量池，直接连接StringTable：查表 + 条件插入，返回最终引用
• 两者都依赖同一个StringTable结构，但入口路径和控制粒度完全不同
• 值得注意的是：ldc解析失败不会抛异常，但intern()在极端内存压力下可能会触发GC或OOM（因为需要分配堆对象）

真正容易被忽略的细节是：JVM对ldc的解析时机并不固定——它可能发生在类加载的解析阶段，也可能延迟到第一次执行该指令时（即“懒解析”）。这意味着，即使两个类都声明了相同的字符串字面量，它们的驻留行为也可能因为加载和执行顺序不同而出现时间差，进而影响==判断的结果。这不是bug，而是JVM为了启动性能所做的权衡。