静态绑定在编译期决定方法调用，动态绑定在运行期根据实际对象类型决定；关键看是否满足非private/非static/非final、被子类重写、通过父类引用调用四个条件。
Java中方法调用的静态绑定与动态绑定怎么区分
编译期决定调用哪个方法，叫静态绑定；运行期根据实际对象类型决定，才是动态绑定。关键看是否满足「非private / 非static / 非final + 被子类重写 + 通过父类引用调用」这四个条件。
常见误判点：static 方法看似被“重写”，实则是隐藏（hiding），调用完全由引用类型决定；private 方法不能被继承，自然不参与多态；final 方法虽可继承但禁止重写，也走静态绑定。
-
invokestatic指令处理static、private、构造器等，绑定在编译期 -
invokevirtual是普通实例方法多态的核心指令，JVM在运行时查虚方法表（vtable）定位具体实现 -
invokedynamic用于Lambda和动态语言支持，与传统多态无关
为什么重载（overload）不体现多态，而重写（override）可以
重载是编译期行为，JVM只看参数类型和数量，跟对象实际类型无关；重写才触发运行期类型判断。哪怕子类对象赋给父类引用，只要调用的是重写方法，就会执行子类版本。
典型陷阱：在父类方法里调用另一个被重写的方法，容易误以为会调用子类实现——其实会，但前提是该调用不是在构造器中发生。构造器中调用重写方法，子类字段可能还未初始化。
立即学习“Java免费学习笔记（深入）”；
- 重载方法签名不同，JVM生成不同符号引用，不进虚方法表
- 重写要求方法签名完全一致（返回类型协变除外），且子类方法不能比父类更严格限制访问权限
- 泛型擦除后，
List<String>和List<Integer>的add()方法仍是同一个签名，不构成重载
如何验证一个方法调用是否真正触发了多态
最直接的方式是打断点或打印日志，但更可靠的是反编译字节码，看调用指令是不是 invokevirtual。也可以用 javap -c 查看。
public class Animal { void sound() { System.out.println("animal"); } }
public class Dog extends Animal { @Override void sound() { System.out.println("woof"); } }
Animal a = new Dog();
a.sound(); // 编译后是 invokevirtual Animal.sound:()V，运行时输出 "woof"
- 如果把
sound()声明为static，javap显示的是invokestatic，输出永远是 "animal" - 若子类未加
@Override注解，IDE可能提示“方法未重写”，但只要签名匹配，JVM仍按重写处理 - 接口默认方法（
default）也可被重写，同样走invokevirtual，但需注意super调用语法限制
多态失效的几种典型场景
不是所有看起来像多态的地方都真能多态。最常踩坑的是字段访问、static 成员、构造器中调用可重写方法，以及泛型类型擦除导致的桥接方法干扰。
- 字段不参与多态：
Animal.name和Dog.name是两个独立变量，访问取决于引用类型 - 构造器中调用
this.sound()，此时子类构造逻辑尚未执行，可能导致空指针或默认值 - 使用
getClass().getName()判断类型再分支调用，等于手动绕过JVM多态机制，性能差且易错 - 泛型类中定义
<T extends Animal> void feed(T animal)，擦除后变成void feed(Animal)，仍可多态；但若写成void feed(List<Dog>)，就无法接收List<Animal>，这是泛型不变性问题，和多态无关
多态本质是运行期方法分派，不是类型转换，也不是自动类型推导。它只发生在方法调用那一刻，而且只对实例方法生效。其他一切看起来像多态的行为，大概率是设计误用或理解偏差。
