符号引用是编译期生成的、与内存布局无关的“名字式”描述，存于Class文件常量池中，如类全限定名、方法描述符等；直接引用是解析阶段生成的、与JVM内存布局相关的物理地址或偏移量，指向已加载目标的实际内存位置。
符号引用是编译期生成的、与内存布局无关的“名字式”描述，它不指向真实地址，只负责在字节码中准确标识目标——比如类名 Lcom/example/Service;、方法描述符 getInfo()Ljava/lang/String;、字段名 count:I。它的存在，是因为 Java 没有传统编译语言的“链接”阶段，所有依赖关系都推迟到运行时由 JVM 解析。
符号引用长什么样？
它存放在 Class 文件的常量池里，是静态的字面量，常见形式包括：
- 类或接口的全限定名，如
"java/lang/Object" - 字段的名称和描述符，如
"value:I"（表示一个 int 类型的 value 字段） - 方法的名称和描述符，如
"toString()Ljava/lang/String;"
为什么不能直接用内存地址？
因为编译时目标类可能还没加载，甚至根本不存在（比如动态代理、SPI 加载、热更新场景）。JVM 无法提前知道 org.apache.commons.lang3.StringUtils 会被哪个类加载器加载、最终落在方法区哪块内存。符号引用提供了一种“延迟绑定”的契约：只要名字对、签名合法、访问权限允许，后续就能找到它。
符号引用什么时候变成真实地址？
在类加载的解析（Resolution）阶段完成转换，但具体时机有弹性：
- 多数情况下，在连接阶段（Linking）的解析子阶段，把常量池里的符号引用替换成直接引用
- 对于虚方法（如普通实例方法），可能延迟到第一次调用时才完成最终绑定（即“动态链接”）
- 如果解析时发现目标类未加载，JVM 会主动触发其加载过程，再继续解析
它和直接引用的根本区别在哪？
符号引用是逻辑的、跨虚拟机一致的；直接引用是物理的、与具体 JVM 实现强绑定的。同一个 CONSTANT_Methodref_info 在 HotSpot 和 OpenJ9 上解析出的指针或偏移量很可能不同，但它们的符号形式（如方法名+描述符）完全一样。这也是 Java 能实现“一次编译、到处运行”的底层支撑之一。
