Java多态详解（一）：向上转型、动态绑定与向下转型避坑指南

从0开始学Java，最让人犯迷糊的往往不是语法写不出来，而是同一个“多态”知识点，不同的人能用完全不同的方式讲，最后越听越玄。我在带新人的时候经常发现，学完封装和继承之后，大家写出来的代码还能正常跑，可一旦看到父类引用指向子类对象，或者方法调用结果和自己预想不一样，脑子里就乱了。JavaSE的Day4，我们就把多态这件事的第一部分掰开揉碎讲清楚：为什么会有多态、向上转型做了什么、方法调用的动态绑定是怎么回事、向下转型要怎么避坑。这篇内容适合正在跟JavaSE自学路线走、已经看完类与对象、封装、继承的读者。

1. 为什么还没学会多态，你的代码已经开始“不对劲”了

1.1 如果只用封装和继承，你要怎么写一个“动物喂食”程序

我经常让新人先做一个小练习：有一个Animal类，里面有Cat和Dog两个子类，现在要写一个方法，分别让猫和狗发出叫声。如果你只会封装和继承，第一反应通常是这样写：

java复制public void letSpeak(Cat c) {
    c.speak();
}

public void letSpeak(Dog d) {
    d.speak();
}

这还没完。过几天产品说，还要加一只Duck。你怎么办？继续再加一个重载方法。每多一种动物，调用方就要多认识一个类型，代码就会越堆越多。这种写法不是不能用，但它让你永远在“为具体类型服务”，而不是“为行为服务”。多态解决的就是这个痛点：我不关心你是猫还是狗，我只知道你是Animal，而Animal会speak()，至于每种动物怎么speak，那是子类自己的事。

1.2 多态的本质：同一个行为，在不同的对象身上有不同表现

用一个生活化的例子理解多态特别快。你手里的电视遥控器，上面有一个“电源”按钮。按下去之后，电视会开，空调遥控器上的同一个“电源”按钮按下去，空调会开。按钮的含义是一样的，只是作用的机器不同，最终行为不同。

程序里的多态就类似这种感觉：一段代码调用的是同一个方法名，但因为这行代码指向的实际对象不同，方法执行出的结果也不同。

java复制Animal a = new Dog();
a.speak(); // 汪汪汪

Animal b = new Cat();
b.speak(); // 喵喵喵

这里两个变量a和b的“静态类型”都是Animal，但两个对象在内存里一个是Dog，一个是Cat。Java允许你把子类对象交给父类类型的变量来管，这个过程叫向上转型，它是多态能够发生的基础。不少人第一次看到这种代码会觉得“不对劲”，其实恰恰是这种“不对劲”，让程序的扩展方式发生了质变。

2. 向上转型：把子类对象交给父类引用，到底发生了什么

2.1 引用类型和实际类型：你以为你拿的是Animal，其实它是Dog

先看最核心的一句话：Java中的变量是有类型的，new出来的对象也是有类型的。变量类型决定你能调哪些方法，对象类型决定方法最终执行谁的版本。

java复制Animal a = new Dog();

左边Animal是变量的“编译器视角类型”，右边Dog是对象的真实类型。这行代码做的事情，是把一个Dog对象的地址保存到Animal类型的变量里。Dog本身就是Animal的子类，所以这种赋值是安全的，Java允许自动完成。

接下来调用方法时就有意思了：

java复制a.speak();

Java虚拟机在运行到这行代码时，不会死板地认为a是Animal就去执行Animal里面的speak()，而是会先看看a真正指向的对象是谁，发现是Dog，最终调用的是Dog重写的speak()。这就叫“编译看左边，运行看右边”。正因为这个机制存在，向上的引用才能让代码写出一种“不确定”的优雅。

2.2 成员变量和静态方法为什么不会跟着对象类型走

方法重写具备“运行期动态绑定”，但有两样东西你一定要注意：成员变量和静态方法，它们不参与这种“运行看右边”的规则。也就是说，Java的多态性主要发生在实例方法上，变量和静态方法仍然是“编译看左边，运行看左边”。

java复制class Parent {
    int num = 10;
    static void hello() {
        System.out.println("Parent hello");
    }
    void print() {
        System.out.println("Parent print");
    }
}

class Child extends Parent {
    int num = 20;
    static void hello() {
        System.out.println("Child hello");
    }
    @Override
    void print() {
        System.out.println("Child print");
    }
}

执行下面这段：

java复制Parent p = new Child();
System.out.println(p.num);   // 输出10，不是20
p.hello();                   // 输出Parent hello，不是Child hello
p.print();                   // 输出Child print

p.num访问的是Parent里定义的num，因为成员变量访问不按照对象的实际类型来，而是按引用变量的类型来。Child里的num其实是把Parent的num“隐藏”了，不是重写。静态方法hello的情况也类似，它属于类，不属于对象，调用时和使用它的引用类型强相关。

所以以后看到有人写“父类引用指向子类对象，所以访问成员变量也会得到子类的值”，一定要纠正过来。真实开发中我建议尽量不要在父子类里定义同名字段，否则非常容易埋坑。

3. 动态绑定：JVM到底怎么选中子类里那个方法

3.1 从invokevirtual开始理解“运行时才决定调谁”

很多初学者把“方法重写”理解成一种代码写法，以为只要子类写了和父类一样的方法，调用就自动生效。这只说对了一半。真正让重写生效的，是Java虚拟机底层的方法分派机制。

当你写好一个Java文件并编译成class字节码时，你写的a.speak()在字节码层面并不会被编译器硬编码成“调用Animal.speak”或“调用Dog.speak”。它生成的是一条类似invokevirtual的指令，指令里带的方法引用指向的是Animal类里的speak()。这里有个关键点：这个引用只是给虚拟机一个“查找起点”，不是最终答案。

程序运行到这条指令时，JVM拿到a变量的实际对象，发现是一个Dog，于是从Dog的方法表里开始查找speak()。Dog重写了speak()，就命中自己那个版本。如果Dog没重写，则继续往父类Animal查找。如果父类也没写，就继续往上。你可以把它理解成从实际类型出发，一层一层向上找“最接近的那个实现”。

这个过程被称为动态绑定、后期绑定或者运行时多态。正是因为绑定发生得这么晚，代码在编写阶段才能保持“抽象”，把具体行为的选择推迟到运行期。

3.2 重载、重写、隐藏，三件事千万别混为一谈

和动态绑定最容易混淆的，就是重载。

重载发生在同一个类中，多个方法名相同但参数列表不同：

java复制public void eat(String food) {}
public void eat(String food, int count) {}

调用哪个重载版本，在编译期就确定了。编译器根据你传的参数决定调用哪个方法，这属于静态绑定，也叫编译期多态，但它和多态特征不是一回事。

重写则发生在父子类之间，要求方法名、参数列表、返回类型完全一致。重写是动态绑定的基础。没有重写，子类只是继承了父类的方法，父类引用调用它时不会产生额外效果。

隐藏是另一个概念。上面说的成员变量和静态方法在子类里重新定义，准确说法叫“隐藏”。由于字段和static方法不会动态绑定，父类引用访问到的永远是父类自己的版本。日常开发里，这种写法几乎没有正面价值，尽量避免。

还有一个细节：父类中被final修饰的方法不允许子类重写，private方法也不存在重写，因为子类压根看不到父类的private方法。很多框架里用final限制方法被子类覆盖，本质就是在“堵死”动态绑定的可能。

4. 向下转型和instanceof：从父类引用“找回”子类身份

4.1 父类引用看不到子类特有方法，该怎么办

向上转型让代码更抽象，但也带来一个问题：如果变量类型是Animal，你就无法通过这个变量调用Dog里独有的方法，比如watchDoor()。

java复制Animal a = new Dog();
a.watchDoor(); // 编译报错，Animal类型里没有watchDoor方法

这不是Java不让你用，而是编译器为了保证类型安全，只会允许你调用变量类型中存在的方法。你想调Dog特有的方法，必须先把a“转回去”，这就叫向下转型。

java复制Animal a = new Dog();
Dog dog = (Dog) a;
dog.watchDoor();

向下转型和向上转型不一样，它不会自动发生，必须写出强制转换的括号。原因是：虽然编译器知道a是Animal，但Animal类型有可能根本不是Dog，强行转可能会出问题。Java把选择权交给你，同时也把风险交给你。

4.2 ClassCastException是怎么来的，instanceof怎么救场

下面这段代码编译可以通过，但运行时会抛ClassCastException：

java复制Animal a = new Cat();   // 注意，指向的是Cat
Dog dog = (Dog) a;       // 运行期发现真实类型是Cat，转成Dog失败

为什么编译能过？因为a的静态类型是Animal，Dog是Animal的子类，编译器认为“Animal转Dog”是有可能成功的。但运行时JVM检查对象真实类型，发现是Cat，与Dog毫无关系，立刻抛异常。

为了避免程序崩溃，标准的做法是先用instanceof检查：

java复制Animal a = new Dog();

if (a instanceof Dog) {
    Dog dog = (Dog) a;
    dog.watchDoor();
} else if (a instanceof Cat) {
    Cat cat = (Cat) a;
    cat.climbTree();
}

instanceof的作用是判断“a这个对象是不是Dog类型，或者Dog类型的子类”。只有结果为true，强制转换才不会出问题。

如果你用的JDK是16或以上，还可以写成模式匹配的简化形式：

java复制if (a instanceof Dog dog) {
    dog.watchDoor();
}

这个语法让代码少了一次显式强转，读起来更舒服。不过很多生产项目可能还停留在Java 8或11，所以传统写法你也要能看懂。

4.3 别把instanceof写满整个方法

向下转型和instanceof确实常用，但我要提醒一句：如果你发现自己在一个方法里连续写五六次instanceof，那很可能说明设计出了问题。

多态本来就是为了让你避免“根据类型做不同处理”的if-else地狱。举个简单例子，与其在主方法里判断“如果是Dog就watchDoor，如果是Cat就climbTree”，不如把行为定义到父类或接口里，让每个子类自己实现。只有当你需要调用子类独有的、不适合放到父类的方法时，往下转型才有必要。在框架源码、反序列化、容器元素恢复具体类型等场景里，instanceof是常规操作，但在普通业务方法里频繁使用，就要反思你的类继承结构是不是合理了。

5. 纸上谈兵不如看三版代码：多态到底让项目好在哪里

5.1 第一版：没有多态时，调用方代码越长越复杂

我们做一个简单场景：动物园要给动物们喂食。

先看没有使用多态时的常规需求：

java复制class Dog {
    public void eat() {
        System.out.println("狗在啃骨头");
    }
}

class Cat {
    public void eat() {
        System.out.println("猫在吃鱼");
    }
}

public class ZooKeeper {
    public void feed(Dog dog) {
        dog.eat();
    }

    public void feed(Cat cat) {
        cat.eat();
    }
}

问题已经很明显了。每新增一种动物，ZooKeeper就得增加一个feed重载方法。而调用ZooKeeper的代码也得知道到底有哪些动物，如果动物以后变成几十种，维护成本会直线上升。

5.2 第二版：引入父类引用和方法重写，调用方终于不用跟着改

把共同的“会吃”行为提取到Animal类中：

java复制class Animal {
    public void eat() {
        System.out.println("动物在吃东西");
    }
}

class Dog extends Animal {
    @Override
    public void eat() {
        System.out.println("狗在啃骨头");
    }
}

class Cat extends Animal {
    @Override
    public void eat() {
        System.out.println("猫在吃鱼");
    }
}

public class ZooKeeper {
    public void feed(Animal animal) {
        animal.eat();
    }
}

这时ZooKeeper的feed只需要认识Animal这一个类型。将来来了一个Panda类，只要继承Animal并重写eat()，ZooKeeper的代码一行都不用改。调用方也不需要知道今天来的是Dog还是Cat，它只需要把对象交给ZooKeeper就行。

这种“对扩展开放，对修改关闭”的思想，正是后续学习设计模式时反复出现的根基。你不需要在这一天就背下开闭原则的定义，但应该能通过这段代码感受到多态给项目带来的自由度——新增逻辑时，原有代码不用频繁伤筋动骨。

5.3 第三版：从实际项目角度看List为什么比ArrayList更常见

多态不只是继承体系里的抽象，在实际项目中最常见的体现之一，是面向接口编程。比如Java集合中经常见到这种代码：

java复制List<String> names = new ArrayList<>();
names.add("小明");

变量类型是List，实际对象是ArrayList。为什么大家喜欢这样写？因为当你的代码只依赖List接口提供的方法时，以后想把ArrayList换成LinkedList，只需要改new的那一行，甚至把对象创建移到工厂方法之后，业务代码完全不受影响。如果变量类型都写死成ArrayList，换实现类时要改的地方就多了不少。

不过初学阶段还没学到集合和接口，可以先在继承场景中建立习惯：能用父类接收的地方，优先用父类接收。父类能提供的抽象，胜过具体子类带来的方便。这不是教你写高深代码，而是提前为后面认识框架源码铺路。

6. 初学阶段最容易踩的两个坑和一份自测清单

6.1 坑一：以为“父类引用指向子类对象”后，一切方法都看子类

这是最常见的误解。有初学者会认为，既然a实际是Dog，那我调用什么方法都应该执行Dog里的版本，包括访问成员变量也应该拿子类的值。

我前面已经解释过，只有实例方法支持动态绑定，成员变量、静态方法、private方法、final方法都不能体现多态。你要记住一个判断方法：先看这段代码发生在编译期还是运行期。重载选择发生在编译期，变量访问发生在编译期，静态方法调用也发生在编译期；只有普通实例方法的调用，才可能推迟到运行期按实际类型找方法。

6.2 坑二：认为父类引用一旦被new成子类，就再也变不回去了

另一种情况是，有些人知道向上转型，却忘了还有向下转型这条路。结果Dog对象里的特有方法一直用不上，只能在业务里绕来绕去。

多态的经典使用方式是“向上抽象，向下恢复”。父类引用保证了代码的统一和扩展性，等到必须使用子类特有能力时，通过instanceof判断后强制转回去，你并没有失去子类的真实身份。对象在内存中不会因为变量类型是Animal就变成Animal，它一直是Dog，只是拿着Animal这个视角观察它而已。

6.3 自测五连问：能答对才算真的理解了

你可以不看代码答案，先在纸上写自己的判断：

1. 没有继承，多态还能发生吗？
   不能。继承或者接口实现，是多态的必要前提之一。多态至少要有一个“父类型”作为统一视角，多个“子类型”提供不同实现。

2. 向上转型之后，调用子类重写的方法，运行时看的是变量类型还是对象类型？
   看对象实际类型。变量类型只负责编译时检查方法是否存在。这也是“动态绑定”名称的由来。

3. 父类引用访问子类中重新定义的同名字段，得到的是父类的值还是子类的值？
   父类的值。字段访问不会多态，是按引用类型来的。

4. 把Animal强转成Dog时，如果不先做instanceof判断，程序可能发生什么？
   编译期没问题，运行期可能抛出ClassCastException。特别是当这个Animal实际new出来的是Cat的时候，异常必然发生。

5. 如果子类没有重写父类的speak()，那么Animal a = new Dog(); a.speak();会执行谁的方法？
   执行父类Animal里的speak()，因为动态绑定在Dog方法表里找不到重写版本，会沿继承链向上找到Animal的实现。这一点也可以验证：重写才是多态效果的来源，没有重写，多态就失去意义。

写这个Day4的笔记时，我一直在想怎么把“多态（i）”这个概念讲得适合初学者。后来我习惯用一个笨办法帮自己复盘：找一张纸，画出Animal、Dog、Cat三个类之间的继承关系，标出每个类里有哪些方法，然后在下面写一行Animal a = new Dog()，分别从编译期视角和运行期视角把a能调用的方法列出来。这个纸面推演看起来很基础，但比疯狂刷题更能帮助建立多态的条件反射。多态不是一个难以理解的语法糖，它更像是一种观察世界的角度，当你开始接受“同一个引用，在不同对象身上呈现出不同行为”时，Java面向对象的大门才真正向你敞开。下一篇我会继续往后聊多态的更多应用场景和设计层面的内容。