动态链接本质是栈帧执行invokevirtual等指令时，按需将常量池中符号引用解析为直接引用的过程：先通过栈帧指针定位常量池项，再结合接收对象实际类型查方法表匹配入口，结果缓存于调用点。
动态链接在字节码执行层面，本质是栈帧中“符号引用→直接引用”的运行期解析过程，其路径不发生在编译时，也不固化在类加载完成时刻，而是在每次方法调用指令触发时，由JVM执行引擎按需完成。关键在于：栈帧本身不存储符号引用的原始字符串，而是通过一个指向运行时常量池的指针，在执行invokevirtual、invokeinterface等指令时，结合当前栈帧的类信息，查表、校验、定位，最终获得可跳转的真实入口。
栈帧里的动态链接字段不是“值”，而是一个常量池索引指针
每个栈帧结构中包含“动态链接”信息，它并非保存完整的符号引用（如"Ljava/lang/String;toString()Ljava/lang/String;"），而是一个轻量级指针——指向当前类的运行时常量池（Runtime Constant Pool）中对应条目的索引。这个索引在字节码里早已写死，比如invokevirtual #25中的#25就是常量池下标。
- 该索引在类加载的解析阶段可能未被解析（尤其对虚方法），仍保持为符号引用形态
- 栈帧创建时，仅复制该索引，不立即解析；真正解析动作推迟到首次执行该调用指令时
- 同一个方法内多次调用同一虚方法，JVM通常会缓存解析结果（如方法表偏移或直接入口地址），后续调用跳过重复解析
解析路径依赖三要素：指令类型 + 当前类 + 实际接收对象
符号引用能否解析、如何解析，取决于字节码指令本身的语义约束和运行时上下文：
-
invokestatic/invokespecial：走静态解析路径，类加载阶段即可完成，不依赖接收者对象；栈帧只需确认方法签名与当前类继承关系，直接绑定到具体实现（如父类构造器、私有方法） -
invokevirtual：典型动态链接场景；执行时先根据栈顶操作数（即接收对象引用）获取其实际Class对象，再查该Class的方法表（vtable），按方法名+描述符匹配，找到实际入口地址（可能是子类重写后的方法） -
invokeinterface：更复杂一层；需遍历接收对象Class所实现的所有接口及其默认/抽象方法，再按接口方法签名匹配，最终确定具体实现类的方法入口（可能涉及itable查找） -
invokedynamic：完全委托给用户定义的Bootstrap Method，解析逻辑不在JVM预设规则内，栈帧只提供调用点句柄（CallSite）和引导参数
从字节码指令到直接引用的四步落地过程
以invokevirtual #30为例，解析发生在该指令被执行瞬间，路径如下：
- 步骤1：从当前栈帧的动态链接指针，定位到运行时常量池第30项 → 得到符号引用（如
Class="java/io/PrintStream", Name="println", Type="(I)V"） - 步骤2：检查操作数栈顶元素，取出对象引用，通过其对象头定位实际Class（如
java/io/PrintStream实例对应的Class对象） - 步骤3：在该Class的方法表中，按
println:(I)V进行精确匹配；若未找到，沿继承链向上查找（如FilterOutputStream → OutputStream）；若仍无，则抛AbstractMethodError - 步骤4：匹配成功后，将目标方法的入口地址（如JIT编译后的native code地址，或解释执行入口）作为直接引用，缓存至该调用点（CallSite），后续同位置调用直接跳转
为什么说“动态”二字体现在栈帧生命周期中
动态链接不是一次性行为，而是与栈帧共存、随调用上下文变化而重新计算的过程：
- 不同栈帧调用同一符号引用，可能解析出不同直接引用（多态本质）
- 栈帧退出时，其动态链接缓存不跨帧保留；新栈帧对相同#号常量池项仍需独立解析（除非全局方法区已缓存）
- 类重定义（HotSwap）、匿名类生成等场景下，原符号引用可能在运行中指向全新Class，导致解析结果变更
- 逃逸分析后栈上分配的对象，其方法调用仍走完整动态链接路径，只是JVM可能做去虚拟化优化（devirtualization），但这属于执行优化层，不改变字节码层面的解析契约
