java动态绑定仅适用于非static、非final、非private的实例方法，jvm通过虚方法表在运行期根据对象实际类型决定调用版本；重载解析在编译期完成，与动态绑定无关。
Java动态绑定只发生在实例方法上
动态绑定不是Java里所有方法都有的特性，它只作用于非static、非final、非private的实例方法
编译器看到 obj.method() 时，如果 method 是上述三类之一，就直接绑定到声明类型（即编译时类型）的方法；否则会推迟到运行期，根据 obj 实际指向的对象类型来决定调用哪个版本。
-
static方法属于类，调用只看引用变量的声明类型，和实际对象无关 -
private方法不能被继承，子类里同名方法是全新定义，不存在“重写”，自然不参与动态绑定 -
final方法禁止重写，JVM可直接内联或静态绑定，跳过运行期查找
为什么父类引用能调用子类重写的方法
这是动态绑定最常被观察到的现象：比如 Animal a = new Dog(); a.speak(); 执行的是 Dog.speak() 而非 Animal.speak()。根本原因在于JVM在执行 invokevirtual 字节码指令时，会查对象的实际类的虚方法表（vtable），而不是变量声明类型的表。
注意这个过程完全由JVM自动完成，不需要显式关键字或配置：
立即学习“Java免费学习笔记（深入）”；
- 只要方法满足动态绑定条件（非static/final/private），且子类确实重写了该方法，就会触发
- 即使子类方法加了
@Override注解，也只是编译检查，不影响运行期行为 - 如果子类没重写，JVM会沿继承链向上查找，直到找到第一个实现版本
容易踩的坑：重载（Overload） vs 重写（Override）
新手常把重载误当成动态绑定的体现——比如在父类和子类中分别定义参数不同的 print(String) 和 print(Object)，然后用父类引用调用，发现总是走父类版本。这是因为重载的解析发生在编译期，依据的是引用变量的声明类型和实参的静态类型，跟实际对象无关。
判断是不是动态绑定，只看一点：方法签名是否完全一致（包括名称、参数类型、返回类型协变）。不一致就是重载，一致才是重写。
- 返回类型不同但参数相同 → 编译错误（不是重写，也不算重载）
- 参数类型不同（哪怕只是
intvsInteger）→ 重载，绑定在编译期完成 - 子类方法抛出更宽泛的异常 → 编译失败，不构成有效重写
动态绑定对性能和调试的影响
现代JVM（如HotSpot）会对频繁调用的虚方法做优化，比如单态内联（monomorphic inlining），把“看起来总是一个实现”的 invokevirtual 替换成直接调用，几乎消除开销。但这也带来一个隐蔽问题：调试时断点可能“跳过”你预期的子类方法，因为JIT已把它内联进父类调用处了。
排查这类问题可以：
- 用
-XX:+PrintInlining查看内联日志 - 临时加
-XX:-TieredStopAtLevel=1禁用C2编译器，让代码保持解释执行状态 - 确认是否真发生了重写：检查字节码里的
invokevirtual指令目标是否指向子类方法
真正需要警惕的不是性能，而是把动态绑定当成“自动多态魔法”——它依赖准确的继承关系、可见性控制和签名一致性，任何一个环节松动，就会退化成静态绑定，而且往往不报错，只悄悄走错路。
