静态绑定在编译期确定方法调用，依据引用类型，适用于private、static、final及构造方法；动态绑定在运行时通过vtable或itable依据实际对象类型分派非私有实例方法或接口方法。
静态绑定发生在编译期，只看引用类型
Java 编译器在编译时就确定了要调用哪个方法，前提是该方法满足：是 private、static、final 方法，或是构造方法。这些方法无法被重写（override），所以没有运行时多态的必要。
- 编译器只检查变量声明的类型（即引用类型），不关心实际指向的对象
- 即使子类定义了同签名的
static方法，父类引用调用的仍是父类版本 -
private方法隐式被final修饰，子类中同名方法只是新定义，与父类无关
class A {
static void m() { System.out.println("A.m"); }
void n() { System.out.println("A.n"); }
}
class B extends A {
static void m() { System.out.println("B.m"); } // 隐藏，非重写
void n() { System.out.println("B.n"); } // 重写
}
A obj = new B();
obj.m(); // 输出 "A.m" —— 静态绑定，看 A 类型
obj.n(); // 输出 "B.n" —— 动态绑定，看 new B()
动态绑定依赖运行时对象类型，靠虚方法表实现
非 private/static/final 的实例方法，在运行时才决定调用哪个版本。JVM 通过对象的实际类查找其虚方法表（vtable），再定位到具体实现。
- 每个类加载时，JVM 会为它生成一张虚方法表，表中按声明顺序存放可被重写的方法入口地址
- 子类虚方法表会覆盖父类对应方法的地址（如果被重写）
- 多态调用本质就是：取对象头中的类指针 → 查该类 vtable → 找方法索引 → 跳转执行
注意：final 实例方法不会出现在 vtable 的可覆盖位置，它被内联或直接调用，不走虚调用流程。
接口方法调用走 itable，不是 vtable
接口方法不能静态绑定（除非是 default 或 static），但它的动态分派机制和类不同：
立即学习“Java免费学习笔记（深入）”；
- 实现类需维护一张接口方法表（itable），记录每个接口方法到实际实现方法的映射
- 同一个接口方法在不同实现类中，itable 条目指向各自的具体实现
- JVM 先根据对象实际类找到其 itable，再按接口类型 + 方法签名查表
常见误区：以为 interface 引用调用默认走和类一样的 vtable。其实它走的是独立的 itable 机制，且在 Java 8+ 中还支持默认方法的继承与冲突解决逻辑。
泛型擦除不影响绑定，但可能掩盖重载歧义
Java 泛型在编译后被擦除，所有类型参数变成 Object 或限定上界。这不会改变绑定类型（该静态还是静态，该动态还是动态），但容易引发重载误判：
- 编译器基于擦除后的签名选择重载方法，可能导致你预期调用子类特化版本，结果选了父类更宽泛的版本
- 运行时仍按对象类型做动态绑定，但前提是重载已确定——而重载决策完全在编译期完成
例如：
void process(List这类错误会在编译时报错，而非运行时异常。s) { ... } void process(List i) { ... } // 编译失败：擦除后都是 process(List)
动态绑定的细节藏在字节码里：invokevirtual 指令触发虚调用，invokestatic / invokespecial 则走静态绑定路径。真正容易被忽略的是：哪怕你写了 obj.method() 看似简单，JVM 内部要查类元数据、跳转表、甚至做去虚拟化优化，整个链路对 GC 和 JIT 都有影响。
