我们都知道，多态的方法调用是「动态绑定」：即编译时无法确定调用哪个子类的重写方法，必须在运行时通过 “对象实际类型” 找到对应的方法。那么什么是动态绑定，而为什么编译时无法确定调用哪个子类的重写方法。
要搞懂动态绑定，我们结合 景区交通工具（自行车 / 观光车 / 缆车） 的例子，从「编译时 vs 运行时」的核心差异入手，用通俗的语言拆解「动态绑定」的本质和原因。
一、先给动态绑定一个「场景化定义」
动态绑定（也叫「运行时绑定」）：调用多态方法时，Java 编译器在编译阶段，只知道 “父类引用有这个方法”，但不知道这个引用实际指向的是哪个子类对象；只有等到程序运行起来，JVM 才会根据「对象的真实类型」，找到并执行对应的子类重写方法。
形象比喻（景区调度场景）
编译时：调度员（编译器）拿到的是一张「景区交通工具」的通用调度单（父类引用），只知道 “所有交通工具都能跑（run 方法）”，但不知道这张调度单最终会分配给自行车、观光车还是缆车；
二、为什么编译时「无法确定」调用哪个子类方法？
核心原因：Java 中「引用类型」和「实际对象类型」是分离的 —— 编译期只关注「引用类型」，而「实际对象类型」要到运行时才确定。
我们分两步拆解，结合代码例子更直观：
第一步：明确两个关键概念（引用类型 vs 实际对象类型）
先看一行熟悉的代码：
// 父类引用 = 子类对象（向上转型，多态的基础）
ScenicVehicle vehicle = new Bicycle("景自A001", true);
这里有两个完全不同的 “类型”，千万不能混淆：
编译器在编译阶段，只能看到左边的「引用类型」，看不到右边的「实际对象类型」—— 它甚至不知道右边的 new Bicycle() 会不会被替换成 new SightseeingCar()（比如加个条件判断）。
第二步：用代码例子证明「编译时无法预知实际对象类型」
我们改造一下调度逻辑，让「实际对象类型」由运行时的条件决定（比如用户输入、随机数）：
import java.util.Random;
public class DynamicBindingDemo {
// 随机生成一种交通工具（运行时才知道是哪种）
public static ScenicVehicle getRandomVehicle() {
Random random = new Random();
int type = random.nextInt(3); // 0=自行车，1=观光车，2=缆车
switch (type) {
case 0: return new Bicycle("景自A001", true);
case 1: return new SightseeingCar("景观B002", 10);
case 2: return new CableCar("景缆C003", "A08");
default: return new Bicycle("景自A004", false);
}
}
public static void main(String[] args) {
// 编译时：只知道 vehicle 是 ScenicVehicle 类型，不知道实际是哪种车
ScenicVehicle vehicle = getRandomVehicle();
// 关键：调用 run() 方法
vehicle.run(); // 编译时无法确定执行哪个子类的 run()，只能运行时确定
}
}
为什么编译时确定不了？
编译器编译 vehicle.run() 时，只能做一件事：检查「引用类型 ScenicVehicle」有没有 run() 方法（因为父类是抽象类，有 abstract void run()，所以编译通过）；但编译器不知道 getRandomVehicle() 会返回自行车、观光车还是缆车 —— 这个结果要等到程序运行时，随机数生成后才知道；既然不知道实际是哪种车，自然无法确定要调用哪个子类的 run() 方法。
第三步：运行时「动态绑定」的具体过程（JVM 是怎么做的？）
当程序运行到 vehicle.run() 时，JVM 会做两件关键事：
先找到 vehicle 引用实际指向的对象（比如随机生成的是 Bicycle 对象）；再查找这个「实际对象类型（Bicycle）」有没有重写 run() 方法 —— 如果有，就执行 Bicycle 的 run()；如果没有（子类没重写），就执行父类的 run()（抽象类不会有这种情况，因为抽象方法必须重写）。
这个 “先找实际对象 → 再找对应方法” 的过程，就是「动态绑定」。
对比：如果是静态绑定（编译时确定）
比如调用 static 方法、private 方法、final 方法（这些方法不能被重写，不支持多态）：
class ScenicVehicle {
// 静态方法（静态绑定）
public static void showType() {
System.out.println("我是景区交通工具");
}
}
class Bicycle extends ScenicVehicle {
// 静态方法不能重写，只是子类自己的方法
public static void showType() {
System.out.println("我是自行车");
}
}
public class StaticBindingDemo {
public static void main(String[] args) {
ScenicVehicle vehicle = new Bicycle();
vehicle.showType(); // 输出：我是景区交通工具（编译时确定调用父类静态方法）
}
}
这里编译时就确定了调用「引用类型（ScenicVehicle）」的 showType()，因为静态方法不支持多态，不需要动态绑定。
三、核心总结：动态绑定的本质 + 编译时无法确定的原因
1. 动态绑定的本质
方法调用的最终目标，由「实际对象类型」决定，而非「引用类型」 —— 这是多态的核心底层机制。
2. 编译时无法确定的核心原因
「引用类型」是编译时确定的，但「实际对象类型」可能在运行时才确定（比如通过条件判断、随机数、用户输入生成对象）；编译器只能检查 “引用类型有没有这个方法”，无法预知运行时的实际对象是什么，所以无法确定要调用哪个子类的重写方法。
一句话记忆（结合景区场景）
编译时：只知道是 “景区交通工具”（引用类型），不知道是哪种车；运行时：看到实际是 “自行车”（实际对象类型），就执行自行车的运行逻辑 —— 这就是动态绑定。