Java多态依赖JVM动态绑定而非编译器推断，通过对象实际类型的虚方法表（vtable）在运行时查表跳转调用重写方法；重载是编译期静态绑定，不属真正多态。
多态靠的是 JVM 的动态绑定，不是编译器“猜”出来的
Java 多态的运行时行为（比如 Animal a = new Dog(); a.makeSound(); 调用的是 Dog.makeSound()）不是编译阶段决定的，而是 JVM 在运行时根据对象**实际类型**查表跳转实现的。编译器只检查 Animal 类里有没有 makeSound() 方法——有就过，没就报错；它完全不管 a 最终指向哪个子类。
虚拟方法表（vtable）是关键数据结构
JVM 为每个类维护一张 vtable，里面存着该类所有可被重写（非 private/static/final）的实例方法的入口地址。父类的 vtable 和子类的 vtable 是独立的，但子类会把重写的方法入口替换成自己的实现地址。
当执行 a.makeSound() 时：
- JVM 通过
a的对象头拿到其**实际类**（这里是Dog） - 查
Dog类的vtable，定位到makeSound()对应的函数指针 - 直接跳过去执行，全程不看引用类型
Animal
为什么重载（Overloading）不算真正多态？
因为 add(int, int) 和 add(double, double) 是**编译期静态绑定**：编译器只看参数类型和引用声明类型，就确定调用哪个版本，连对象实际类型都不读。这跟“一个接口、多种实现”的多态本质无关，只是语法糖级别的便利。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
常见误判点：
-
Calculator calc = new Calculator(); calc.add(1, 2);→ 绑定在编译时完成，跟多态无关 -
Animal a = new Dog(); a.eat();（eat()没被重写）→ 仍走Animal.eat()，这是多态的合法情况（默认实现），不是“失效” - 子类新增方法（如
Dog.guardHouse()）无法通过Animal引用调用 → 向上转型后，引用只能访问父类声明过的成员
向下转型失败时抛 ClassCastException 的根源
当你写 Cat c = (Cat) new Dog();，JVM 运行时发现对象实际类型是 Dog，而目标类型是 Cat，两者无继承关系，立刻抛异常。这不是多态机制的问题，而是类型系统在阻止非法转换。多态只要求“向上转型安全”，从不保证“向下转型一定成功”。
真正需要向下转型的场景，往往说明设计上可以改用多态+模板方法或 Visitor 模式来避免——这点在大型项目里容易被忽略。
