动态绑定发生在运行时JVM执行invokevirtual指令时，针对非静态、非final、非私有的实例方法，根据对象实际类型查vtable调用对应实现。
动态绑定发生在方法调用的哪个时刻
动态绑定（Dynamic Binding）不是在编译期决定的，而是在运行时、当 JVM 执行到 invokevirtual 字节码指令时才真正发生。它只对 public、protected 和包访问权限的**非静态、非 final、非私有**实例方法生效。静态方法、私有方法（private）、构造器、final 方法都走静态绑定——它们的调用目标在编译期就锁死了。
常见误解是“只要用了父类引用指向子类对象，就一定动态绑定”，其实不然：如果调用的是 static 方法，哪怕签名完全一样，JVM 也只看引用变量的**声明类型**，而不是实际类型。
-
obj.method()中的method若为static→ 绑定到obj声明类型对应的类 -
obj.method()中的method若为实例方法且满足条件 → 绑定到obj实际运行时类型（即new出来的那个类）
JVM 怎么找到该调用哪个版本的方法
JVM 为每个类维护一张虚方法表（vtable），表中按声明顺序存放所有可被重写（overridable）的实例方法的入口地址。子类的 vtable 会继承父类 vtable，并把被重写的方法项替换成自己的实现地址。
当执行 invokevirtual 指令时，JVM 做三件事：
立即学习“Java免费学习笔记（深入）”；
- 查操作数栈顶对象的实际类型（比如是
Child类实例） - 取该类型的 vtable，定位到对应方法在表中的索引位置
- 跳转到该索引处存储的内存地址执行
这个过程不涉及反射或字符串匹配，所以开销极小。但要注意：vtable 是类加载阶段生成的，因此新增子类不会影响已有类的 vtable 结构；而接口方法（invokeinterface）不使用 vtable，而是用更耗时的 ITABLE 查找，这是接口多态性能略低的原因之一。
为什么重载（overload）不参与动态绑定
重载是编译期行为，由编译器根据**参数数量、类型、顺序**以及**引用变量的声明类型**来决定调用哪个方法。它和运行时对象的实际类型无关。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
例如：
class A { void m(Object o) { System.out.println("A:Object"); } }
class B extends A { void m(String s) { System.out.println("B:String"); } }
A a = new B();
a.m("hello"); // 编译报错！因为 a 的声明类型是 A，A 中没有 m(String)
上面代码根本无法通过编译。即使改成：
A a = new B(); a.m(new Object()); // 输出 "A:Object" —— 绑定依据是 a 的声明类型 A，不是 new B()
这就是重载与重写的关键分水岭：重载看“左边”（引用类型 + 参数字面量），重写看“右边”（堆中对象的真实 class）。
容易被忽略的陷阱：字段访问不触发动态绑定
Java 中只有**方法调用**支持动态绑定，字段（成员变量）访问永远是静态绑定。哪怕子类定义了同名字段，也只会根据引用变量的声明类型来决定访问哪一个。
class Parent { String name = "Parent"; }
class Child extends Parent { String name = "Child"; }
Parent p = new Child();
System.out.println(p.name); // 输出 "Parent"，不是 "Child"
这常导致初学者误以为“多态也适用于属性”，结果在调试时发现字段值没变。解决办法只有一个：把字段封装成 getter 方法——只有方法才能享受动态绑定。
另一个隐性坑是：匿名内部类或 Lambda 表达式捕获外部变量时，若该变量是实例字段，背后实际访问的仍是声明类型的字段副本（尤其在继承链中混用时），务必用 this.xxx 或显式 getter 显化意图。
