ldc指令是Java虚拟机中加载常量池常量的核心入口，它通过操作数栈上的索引值，从运行时常量池中精确取出对应的常量，再压入操作数栈顶，整个过程高效且无副作用，是JVM执行引擎中最基础也最高频的字节码指令之一。ldc承担的职责就是“按图索骥”，将编译期写入class文件的符号引用，在运行期解析为真实的数据对象。
理解ldc指令前必须知道的常量池本质
运行时常量池和class文件常量池的关系
Java源码编译成.class文件时，所有用到的字符串字面量、final常量、类名、方法名都会被塞进class文件里的“常量池表”，这个表是静态的，只存在于磁盘上，当JVM加载这个类时，会把class文件常量池里的内容搬运到内存中的“运行时常量池”，这个过程叫常量池解析。
运行时常量池是方法区的一部分,在JDK 7及以后，它被移动到堆内存中，但这不是关键，关键是ldc指令操作的就是这个运行时常量池。
ldc指令的字节码格式
ldc指令在字节码层面非常简短：一个操作码（0x12），紧跟一个1字节的无符号索引值，这个索引值指向运行时常量池的某个位置，1字节意味着范围只有0到255，所以当常量池条目超过256个时，JVM工程师搞出了ldc_w指令，它的索引是2字节，范围更大。
ldc指令的完整工作流程可以拆成四步：
- 从字节码中读取操作码,识别为ldc
- 读取紧跟的1字节索引值
- 用它去运行时常量池中查找对应的常量项
- 将常量值压入当前线程的操作数栈顶
如果索引指向的常量还没有被解析,JVM会触发解析动作，这个过程叫常量池动态解析，是ldc指令比较特殊的环节。
ldc指令和ldc_w指令的区别：不只是字节数不同
很多人在看字节码时会疑惑：什么时候用ldc，什么时候用ldc_w？这里有一个简洁的判断标准。
| 对比项 | ldc | ldc_w |
|---|---|---|
| 操作码 | 0x12 | 0x13 |
| 索引长度 | 1字节 | 2字节 |
| 索引范围 | 0~255 | 0~65535 |
| 栈操作 | 压入一个值 | 压入一个值 |
| 使用频率 | 极高 | 较少 |
javac编译器在生成字节码时,会先统计常量池条目总数，如果确信索引值不超过255，就用ldc；如果可能超过，就用ldc_w，这个选择是在编译期完成的，和运行期性能没有关系。
常量池索引为0的特殊性
运行时常量池的索引0是保留项,不指向任何常量，所以ldc的索引范围虽然理论上可以是0到255，但实际可用的起始索引是1，这个细节在写字节码增强工具或手写ASM代码时经常踩坑。
用javap查看ldc指令具体怎么加载常量
准备一段简单代码
public class LdcDemo {
private String name = "张三";
private final int age = 18;
public String greet() {
return "你好，" + name;
}
}
编译后执行：
javap -verbose LdcDemo.class
在greet()方法的字节码中，你会看到类似这样的输出：
0: ldc #7 // String 你好， 2: aload_0 3: getfield #9 // Field name:Ljava/lang/String; 6: invokedynamic #13 // Method makeConcatWithConstants
这里的ldc #7就是核心。#7是常量池索引，// String 你好，是javap帮我们反查出来的常量值，这个过程中，ldc指令从常量池第7个位置取出了字符串对象，然后压入操作数栈。
字符串常量的特殊处理
对于字符串,ldc指令的行为和其他常量不太一样，字符串常量在运行时常量池中记录的其实是一个指向字符串对象的引用，而不是字符串本身，当ldc执行到字符串常量时，JVM会检查堆中是否已有内容相同的字符串对象，如果有就复用，没有就创建新的，这就是
字符串常量池的驻留机制和ldc的关系。
为什么System.out.println会被拆成多条指令
System.out.println("Hello");
对应的字节码是：
0: getstatic #2 // Field System.out 3: ldc #3 // String Hello 5: invokevirtual #4 // Method println
getstatic把System.out压栈，ldc把”Hello”字符串压栈，invokevirtual调用println方法并消耗栈顶两个值，所以ldc只是负责“取数据”，真正干活的是后面的指令，这种分工让JVM的执行引擎可以非常流水线化地工作。
不同数据类型的ldc加载行为对比
基本类型常量的加载
对于int类型,JVM有多种指令可选：iconst用于-1到5，bipush用于-128到127，sipush用于-32768到32767，ldc用于更大范围的int，编译器会根据具体数值选择最节省字节码空间的方案。
int a = 100; // bipush 100 int b = 1000; // sipush 1000 int c = 100000; // ldc #5
float、double类型的常量也走ldc指令，double还用ldc2_w（操作码0x14）加载64位数据，这个细节和ldc_w不同，ldc2_w加载的是一个64位值，会占用操作数栈的两个槽位。
类和Class对象的加载
这是ldc指令比较有意思的用法,当你写String.class时，javac生成的也是ldc指令，只是常量池条目类型是CONSTANT_Class_info。
Class<?> cls = String.class;
字节码是：
0: ldc #3 // class String
当ldc指令遇到Class常量时,会触发类的加载和初始化逻辑吗？答案是：会触发类的加载，但不会触发初始化，JVM规范明确区分了ldc对Class常量的处理：只有
new、invokestatic等指令才会触发主动初始化，ldc只负责把Class对象准备好，不触发<clinit>的执行，但有个例外，如果访问的是自身类，会触发初始化，因为此时<clinit>已经在执行了。
MethodHandle和MethodType的延迟解析
这在Java 7引入的方法句柄支持中比较特殊，ldc指令遇到CONSTANT_MethodHandle_info时，会进行更复杂的解析：需要解析前面的类、方法名、描述符，然后生成一个MethodHandle对象，这个过程比普通字符串加载慢得多，所以在性能敏感的场景中，不要频繁在循环里用ldc加载方法句柄。
一个容易忽略的事实：ldc加载出的对象可能每次不同
很多开发者以为ldc加载字符串常量时,每次返回的都是同一个对象，这个认知需要修正：
字符串字面量由ldc触发驻留，驻留的时机是首次执行到该ldc指令时，驻留后，后续再执行同一个ldc指令，返回的是同一个字符串对象，但如果你在代码里用new String("abc")创建新对象，虽然内容相同，但ldc返回的是驻留池里的对象，new出来的对象是不同的。
String s1 = "hello";
String s2 = "hello";
// s1 == s2 返回 true，因为都是ldc从常量池加载的同一个对象
String s3 = new String("hello");
// s1 == s3 返回 false
这里对Java虚拟机中ldc指令加载常量池常量的机制做了一个实战视角的拆解,在面试中，当被问及ldc指令如何工作时，可以直接说：ldc通过常量池索引加载数据并压入操作数栈，触发字符串驻留和类解析，是JVM执行引擎中连接字节码与运行时常量池的桥梁。
在实际开发中,理解ldc的工作机制对排查字符串驻留问题、优化高频方法调用、甚至是写字节码插桩工具都有实际帮助，通过javap -verbose观察ldc指令的实际行为，是验证JVM执行模型最直观的手段。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/621828.html
