静态链接发生在类加载的解析阶段，即类首次主动使用前，JVM将符号引用（如类名、方法名）替换为内存中确定位置（如常量池索引、vtable偏移等），且只执行一次。
静态链接发生在什么时候？
Java 类文件里所有方法调用、字段访问，只要不是 invokedynamic，都以符号引用形式存在——比如类名、方法名、描述符拼成的字符串。静态链接就是 JVM 在类加载的「解析阶段」，把这类符号引用替换成内存中确定的位置（比如类的常量池索引、方法表偏移、字段偏移）。这个过程在类首次主动使用前就完成了，且只做一次。
常见错误现象：java.lang.NoSuchMethodError 或 java.lang.NoSuchFieldError，往往不是运行时才出问题，而是静态链接失败后抛出——说明符号引用存在，但目标在当前类路径下根本没找到对应的实际成员。
注意点：
- 接口方法默认不解析（直到首次调用才触发）
-
final方法、私有方法、构造器，JVM 通常会直接静态链接，因为它们无法被重写 - 如果类 A 引用了类 B 的静态字段，而类 B 尚未初始化，JVM 会先触发 B 的初始化，再完成该字段的静态链接
动态链接为什么必须存在？
因为 Java 支持多态和运行时类加载，编译期无法确定最终执行哪个方法。比如 invokevirtual 指令只记录符号引用，实际调用目标得等运行时看对象实际类型才能决定。JVM 把这部分逻辑交给「虚方法表（vtable）」或「接口方法表（itable）」，每次调用都查表跳转——这就是动态链接。
使用场景：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 普通实例方法调用（非
final/private/static） - 接口方法调用（
invokeinterface） - 反射调用（
Method.invoke()）底层也依赖动态链接机制
性能影响：现代 JVM（如 HotSpot）会对热点虚调用做「内联缓存（IC）」甚至「去虚拟化」，但首次调用仍需查表；若子类频繁加载/卸载（如 OSGi、热部署），可能使 IC 失效，导致性能抖动。
符号引用转直接引用到底替换了什么？
不是“把字符串换成地址”这么简单。它替换的是字节码指令中对常量池的索引引用，指向一个「运行时常量池项」，而这项本身会被更新为具体结构体指针：
- 类引用 → 指向
Klass*结构体（HotSpot 内部表示） - 字段引用 → 指向
_offset偏移量 + 所属类的Klass* - 方法引用 → 指向
Method*指针，或 vtable/itable 中的槽位索引
关键区别：ldc 加载字符串常量，走的是常量池缓存；而符号引用解析后的直接引用，是 JVM 运行时数据结构的硬指针，不经过常量池查找。这也是为什么 String.intern() 和方法解析互不影响。
容易被忽略的陷阱：解析时机与类加载器隔离
符号引用能否成功解析，不仅取决于类是否存在，更取决于「解析请求发起者」和「目标类」是否由同一个类加载器加载。跨加载器的引用（比如 Web 应用中自定义类加载器加载的类引用了 Bootstrap 类加载器的 ArrayList）看似没问题，但若中间夹了一个由 Extension 类加载器加载的类，就可能因双亲委派链断裂导致解析失败。
典型错误：java.lang.LinkageError: loader constraint violation，本质是多个类加载器各自解析了同一名字的类，但 JVM 发现它们的符号引用本应指向同一个运行时类，却指向了不同 Klass* 实例。
调试建议：
- 加 JVM 参数
-XX:+TraceClassLoading和-XX:+TraceClassResolution观察解析日志 - 用
jstack -l看线程栈时注意类加载器 hash 值是否一致 - 避免在自定义类加载器中重写
loadClass(String, boolean)时绕过双亲委派，除非你完全掌控符号引用的可见范围
