Java动态链接在类加载解析阶段将符号引用替换为直接引用，支撑多态、接口调用与反射；采用懒解析策略，按需触发，并在失败时抛出LinkageError子类错误。
Java 的动态链接发生在类加载的“解析”阶段，核心是把字节码里的符号引用（Symbolic Reference）替换成运行时可直接使用的直接引用（Direct Reference）。这个过程不是在编译期完成的，而是在类加载过程中由 JVM 动态完成的，支撑了 Java 的多态、接口调用、反射等机制。
符号引用 vs 直接引用
符号引用是以一组符号来描述所引用的目标，比如类名、字段名、方法名和描述符（如 "Ljava/lang/String;"），它不关心内存布局，只依赖字符串匹配和语义规则。直接引用则是能直接定位到目标的指针、偏移量或句柄，与内存布局强相关。
例如：
符号引用：`invokestatic #5` 中的 `#5` 指向常量池第 5 项，内容可能是 `"java/lang/System.out:Ljava/io/PrintStream;"`；
直接引用：JVM 解析后，该指令实际指向 `System.out` 这个静态字段在堆中的具体对象地址，或其在类数据区的偏移量。
解析发生的时机与触发条件
解析并非一次性全部完成，而是“懒解析”（Lazy Resolution）——只有当某条字节码指令首次执行到需要该符号引用时，JVM 才去解析它（部分情况如 static final 常量会在准备阶段就解析完毕）。
- 遇到 new、getstatic、putstatic、invokestatic 等指令时，会触发对类、字段、静态方法的解析
- 遇到 invokevirtual 或 invokeinterface 时，会解析目标方法的符号引用（但不会在此刻决定具体调用哪个实现，那是虚方法表查表的事）
- 使用反射（如 Class.forName()、Method.invoke()）也会触发隐式解析
解析的关键步骤与检查逻辑
以解析一个非接口的静态方法为例，JVM 主要做以下几件事：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 根据符号引用中的类全限定名，确保对应类已被加载、验证、准备（若未加载则触发类加载）
- 在该类的方法表中查找匹配的方法名和描述符（注意：描述符必须完全一致，包括参数类型和返回值）
- 检查访问权限（如 private 方法不能被外部类解析成功）
- 确认方法不是抽象的（除非是接口默认方法或静态方法）
- 将找到的方法元数据（如 Method 对象、入口地址、vtable/itable 索引等）封装为直接引用，缓存到常量池中，后续相同引用直接复用
对于接口方法，解析还会额外检查目标类是否实现了该接口，以及该接口方法是否为 default 或 static。
解析失败的典型场景
解析失败会抛出 NoSuchMethodError、NoSuchFieldError、IncompatibleClassChangeError 等错误，常见于：
- 运行时类路径中缺失某个依赖类（NoClassDefFoundError 实际常在解析前就抛出）
- 方法签名变更后未重新编译调用方（如改了参数类型，但调用字节码仍按旧符号引用解析）
- 子类覆盖父类方法时违反协变返回类型规则，导致解析时类型不兼容
- 模块系统下（Java 9+）跨模块访问未正确导出（IllegalAccessError 可能在解析阶段或链接后期抛出）
这些错误属于 LinkageError 子类，说明链接阶段出了问题，而非运行时异常，通常意味着构建或部署不一致。
基本上就这些。动态链接的本质，就是让字节码保持“符号中立”，把绑定推迟到运行期，由 JVM 在安全可控的前提下完成落地。它不复杂，但容易忽略细节——尤其是版本不一致和模块边界带来的解析限制。
