1. 多态到底解决了什么问题——从没有多态的代码说起很多 Java 初学者对多态的印象停留在多个子类中同样的方法有不同的实现这个说法没毛病但它只回答了多态是什么没回答多态为什么存在。而不理解后者写代码的时候就不知道怎么用它面试时也只会背概念稍微变个问法就垮掉。1.1 没有多态时代码长什么样想象你接到一个需求动物园的每个动物都要发出声音。假如系统里已经存在 Dog 和 Cat 两个类但还没有引入多态你要写一个方法让传入的动物都能叫大概率会写成这个样子public void makeSound(Object animal) { if (animal instanceof Dog) { System.out.println(汪汪汪); } else if (animal instanceof Cat) { System.out.println(喵喵喵); } else { System.out.println(未知动物); } }这个代码的问题不是它错了而是每增加一种动物你就要打开这个方法加一个 else-if 分支。今天加 Bird明天加 Panda这个方法会越来越长越来越难看。而且调用方必须知道系统里有哪些动物类型代码的耦合度高得离谱——新增一个动物类既要改调用方又要改这个判断方法漏改一处就出 bug。多态要消灭的正是这种靠 if-else 区分类型的写法。它的核心思路极其朴素熊会叫猫会叫狗也会叫那为什么不让每个动物自己负责自己的叫声调用方只需要对着动物喊一声由具体动物自己去决定怎么回应1.2 多态的代码形态引入多态之后代码变成这样abstract class Animal { public abstract void speak(); } class Dog extends Animal { Override public void speak() { System.out.println(汪汪汪); } } class Cat extends Animal { Override public void speak() { System.out.println(喵喵喵); } } public void makeSound(Animal animal) { animal.speak(); // 调用方完全不需要关心它是 Dog 还是 Cat }以后再加入 Bird 类只需要让 Bird extends Animal 并重写 speak() 方法makeSound 方法一行都不用改。这就是多态最直接的红利面向抽象编程新增行为不需要修改已有代码也就是开闭原则对扩展开放对修改关闭的直观体现。1.3 三个必要条件多态能成立有几个硬性条件缺一个都不行继承必须有父类或接口子类或实现类继承/实现它。Java 的单继承限制对多态有一定影响所以接口在这种场景下越来越重要后面会专门讲。重写子类必须重写父类的方法否则调用的还是父类逻辑没有多种行为可言。父类引用指向子类对象也就是Animal a new Dog()在编译期用父类类型声明变量在运行期才把具体的子类对象装进去。这事听着像静态类型语言里很平常的一个语法点但一句话概括就是变量的类型决定你能调用哪些方法对象真正的类型决定方法执行什么逻辑。这两个决定发生在不同时期正是多态的全部秘密。2. 方法调用真相编译看左边运行看右边编译看左边运行看右边是 Java 多态最经典的一句口诀但很多人只是背会了这句话没搞清楚左边和右边分别做了什么。这块我尽量讲透因为它牵扯到编译器、字节码、JVM 方法分派三层机制。2.1 编译期编译器只认左边的类型Animal a new Dog(); a.speak();编译器看到的是a.speak()它会去 Animal 类中寻找名为 speak、参数列表为空的方法。找到了编译通过找不到直接报错——哪怕 Dog 类里有一个子类特有的 fetch() 方法你也无法通过 Animal 类型的引用去调用它。Animal a new Dog(); a.fetch(); // 编译报错找不到符号 fetch()这个限制对新手来说经常很别扭明明 new 的是 Dog为什么调不了 Dog 独有的方法因为编译器只负责静态检查它无法保证运行时期传进来的对象一定是 Dog。如果允许这样写万一运行期传入一个 Cat根本没有任何 fetch 方法可用程序安全就成了问题。所以 Java 选择了让编译期更严格、让运行期更安全的设计。2.2 运行期JVM 根据实际对象决定执行逻辑pass 编译后a.speak()在字节码里长这样invokevirtual #4 // Method Animal.speak:()V注意看字节码里存的是Animal.speak这个符号引用指向 Animal 类的方法定义位置但它不是硬编码成 Animal.speak 的地址。JVM 在运行期执行 invokevirtual 指令时会去取出a 变量里实际对象的类型在这个实际类型的类中查找 speak() 方法。这里 a 里装的是 Dog 对象于是真正执行的是 Dog.speak()如果 a 里装的是 Cat 对象执行的则是 Cat.speak()。这正是运行看右边的底层含义分派的行为发生在运行期而且分派依据是实际对象类型不是变量声明的类型。2.3 为什么一定要有父类引用有人会问那我干脆不写Animal a new Dog()直接写Dog a new Dog()不行吗也能工作但问题在于——你写一个方法接收 Animal是让这个方法面向 Dog 和 Cat 所有子类同时工作如果你把方法参数写成 DogCat 就传不进来了代码的复用性大打折扣。父类引用最大的价值在于它能装下该父类所有子孙类型的对象。这就像你设计的接口是所有 USB 设备那么 U 盘、鼠标、键盘都能插上来用如果你在接口上写死只能用罗技鼠标那 Cherry 键盘就进不来了。多态里的父类引用就是为了让你在写逻辑时分得清自己面对的是哪一层的抽象。2.4 字段不参与这种分派有一个让人意外的事实是字段访问不会走动态分派机制。看下面这段代码class Animal { String name 动物; } class Dog extends Animal { String name 小狗; } Animal a new Dog(); System.out.println(a.name); // 输出动物不是小狗Java 中字段的访问在编译期就确定了它按照引用变量的声明类型来定位字段与运行期的实际对象无关。所以a.name访问的是 Animal 类的 name 字段。如果你要强制访问 Dog 类的 name必须向下转型Dog d (Dog) a; System.out.println(d.name); // 输出小狗这个特性在实际编码中是个坑——以为通过父类引用访问到的是子类字段结果拿到的是父类的。后面第 6 章会结合构造器讲得更细。3. 三类常见多态形态重写、重载与接口实现严格来说Java 里的多态可以分为编译期多态和运行期多态两种形态。面试时如果能把这一点讲清楚就已经超过一大半的人了。3.1 方法重写运行期多态的正主方法重写是运行期多态的典型代表。它有几个硬性要求方法名、参数列表必须完全相同返回类型可以相同也可以是原返回类型的子类型协变返回访问权限不能低于父类方法不能抛出比父类方法更宽泛的受检异常。很多时候面试官会假装不经意地问重写和重载有什么区别其实问的就是什么是运行期多态什么是编译期多态。重写有 Override 注解辅助检查父类没有这个方法时编译期就会报错这种设计是为了让开发者在重写时少犯低级错误——如果你以为自己在重写实际写成了重载编译期会直接提示你。3.2 方法重载编译期的假多态方法重载是在同一个类中定义多个同名方法但参数列表不同。它属于静态分派也就是编译器在编译阶段就决定了调用哪个方法。看一个经典例子class Calculator { public int add(int a, int b) { return a b; } public double add(double a, double b) { return a b; } }调用时传入 int 就走 int 版本传入 double 就走 double 版本这个决定是在编译期做的。重载里有个容易迷糊的细节如果传参类型同时兼容多个重载版本Java 会按照最精确匹配原则选择方法。比如add(1, 2)在双 int 版本存在时不会跳到 double 版本因为 int 比 double 更精确。3.3 接口与抽象类多态的高级形态接口的出现把多态往前推了一大步。前面说过 Java 是单继承一个类只能有一个父类但可以实现多个接口。这使得一个对象有多种身份这种多态玩法变得极其自然。interface Flyable { void fly(); } interface Singable { void sing(); } class Bird implements Flyable, Singable { Override public void fly() { System.out.println(鸟在飞); } Override public void sing() { System.out.println(鸟在唱); } }Bird 对象既可以被当作 Flyable 用也可以被当作 Singable 用还能被当作 Bird 用。这种多接口设计让代码的抽象层次更丰富。在实际项目中当你需要区分一个对象能力的边界时接口是最好用的工具——你不需要知道它是什么鸟只需要知道它能飞。3.4 三者对比维度方法重写方法重载接口实现发生层级父类与子类之间同一个类内部实现类与接口之间分派时机运行期动态分派编译期静态分派运行期方法签名相同参数必须不同相同关键字Override无implements典型意义体现多态语法便利定义能力契约从面试角度看回答重写 运行期多态重载 编译期多态是一个加分点能从字节码角度解释更显得有深度。但这一切的前提是你真的理解而不是背句子。4. 向上转型与向下转型安全的变脸法则多态代码写多了必然遇到类型转换。转换看似简单一不留神就出 ClassCastException所以这块值得单独开一章把安全的转法讲清楚。4.1 向上转型让代码面对抽象把子类对象赋给父类引用就是向上转型。这个操作永远是安全的因为子类一定拥有父类的所有成员父类引用能用的方法子类一定都有。它也是多态的前提——你首先得把 Dog 塞进 Animal 引用里后面才有编译看左边、运行看右边这回事。向上转型在方法参数上的价值最明显public void feed(Animal animal) { animal.eat(); }这个方法不关心 animal 是 Dog 还是 Cat因此未来无论新增多少个 Animal 子类这个方法都无需修改。这就是面向抽象编程的核心意义——高层不依赖细节细节负责实现自己。4.2 向下转型的风险向下转型是把父类引用强行转回子类类型。为什么要有这种操作因为有些子类特有的方法在父类引用上无法调用。比如Animal a new Dog(); ((Dog) a).fetch(); // 安全因为 a 实际是 Dog但如果对象实际不是 Dog 类型转型就会直接抛异常Animal a new Cat(); Dog d (Dog) a; // 运行期抛出 ClassCastException这个异常之所以是运行期而不是编译期是因为编译器无法判断 a 的运行时类型。Java 的设计哲学是编译期管语法运行期管验证。所以向下转型前必须做类型检查。4.3 instanceof 的正确写法传统写法是if (a instanceof Dog) { Dog d (Dog) a; d.fetch(); }从 JDK 16 开始Java 提供了模式匹配的写法简化了这种重复代码if (a instanceof Dog d) { d.fetch(); // d 已经自动转型好了 }模式匹配是近年 Java 语言里少有的、在可读性上取胜的特性。它把判断类型 强转 声明新变量合并成一步代码干净很多。这里想多说一句写代码时如果发现自己经常要用 instanceof 去判断类型再执行不同逻辑可以先停下来想一想——是不是可以用多态把这段逻辑拆出去如果调用方需要对每种子类做不同处理说明抽象的目标没有设计好或者这几种子类之间根本没有共同抽象需要重新梳理类结构。5. 藏在 JVM 里的多态方法表与动态分派多态看起来只是语法层面的东西但 JVM 为了执行多态底层做了很多工作。这部分内容面试不太常问但理解它之后你对 Java 的方法调用会有一个更体系的认知。5.1 虚方法与非虚方法Java 的方法分为两类虚方法virtual method和非虚方法non-virtual method。实例方法在默认情况下都是虚方法它们参与动态分派。而以下几类方法不参与动态分派静态方法invokestatic 调用私有方法invokespecial 调用final 方法虽然字节码用 invokevirtual但编译器会优化掉它的动态分派构造函数invokespecial 调用super 关键字调用的父类方法invokespecial 调用。观察 javap 输出时你会看到不同的指令invokestatic、invokespecial、invokevirtual。其中 invokevirtual 就是动态分派的入口是它实现了运行看右边。5.2 方法表的工作方式为了高效执行动态分派JVM 在类加载阶段为每个类生成一张方法表Method Table记录了类中所有虚方法的实际入口地址。表的结构大致如下Animal 类的方法表 | Object.toString() | - Object.toString 入口 | | Animal.speak() | - Animal.speak 入口 | | Animal.eat() | - Animal.eat 入口 | Dog 类的方法表 | Object.toString() | - Object.toString 入口 | | Animal.speak() | - Dog.speak 入口 | | Animal.eat() | - Dog.eat 入口 |关键点在于Dog 类的方法表中speak() 槽位指向的方法已经替换为 Dog 自己的实现。当执行 invokevirtual 时JVM 只需要拿到对象实际类型对应的方法表按下标索引直接跳到对应方法入口效率非常高。5.3 现代 JVM 的优化手段早期的 JVM 是纯解释执行多态调用的开销相对明显。现代 JVM尤其是 HotSpot在 JIT 编译阶段会对多态调用做大量优化类型继承关系分析CHAJVM 会分析当前已加载的类中,某个方法有多少种实现。如果只有一种实现它可以直接内联甚至去掉分派。内联缓存Inline Cache如果方法有多种实现JVM 会记录最近一次调用的目标类型。下次调用如果还是这个类型直接走缓存遇到新类型再重新分派。方法内联把被调用的方法体直接嵌入到调用方代码中消除调用开销。这些优化对普通开发者来说是无感的但了解它们至少能帮你破除两个误解一是多态一定很慢——实际上 JIT 优化后多态调用的性能和直接调用非常接近二是Java 代码没法手动调优——高质量代码配合 JVM 自动优化才是效率的正解。5.4 动态代理、Lambda 与多态的内在联系JDK 动态代理要求目标类必须实现接口本质上就是利用接口的多态性代理类和目标类实现同一个接口调用方持有接口类型引用运行期真正执行的是代理类的方法。Spring 的 AOP 之所以能工作就是把调用方 - 目标对象的引用关系悄悄替换成了调用方 - 代理对象而代理对象又通过方法拦截器转调目标对象。Lambda 表达式就更直接了——它在字节码层面通过 invokedynamic 指令调用一个契约方法具体执行体由运行期决定。可以说Java 从语言特性到框架生态处处都有多态的痕迹。6. 多态高频面试题陷阱构造器、字段与静态方法多态的概念不难但实际题目里陷阱很多。这里整理几种出现频率非常高的考察方式每个都是真实面试题改编。6.1 构造器里调用被重写的方法看这段代码class Parent { Parent() { show(); } void show() { System.out.println(Parent show); } } class Child extends Parent { private String info init; Child() { super(); info after; } Override void show() { System.out.println(info); } } public class Main { public static void main(String[] args) { new Child(); } }问你输出是什么答案是null。我来解释一下发生了什么new Child() 时会先调用 Child 的构造方法而 Child 构造方法的第一行隐式调用了 super()也就是 Parent 的构造方法。Parent 的构造方法里调用 show()由于 show 是虚方法动态分派发生后实际执行的是 Child 重写后的 show()。但此时 Child 还没有完成实例化info 字段还没有被赋值为 init还记得吗字段先赋默认值再在构造器中赋值因此输出的是默认值 null。这个题目考察的核心就是两个点构造器调用链中动态分派照样生效字段初始化发生在构造器赋值之前。实际开发中尽量避免在构造函数里调用可以被子类重写的方法否则可能引发这种难以排查的问题。如果确实需要可以用私有方法或 final 方法替代。6.2 字段遮蔽不是重写再来一个class Parent { int num 10; } class Child extends Parent { int num 20; } Parent p new Child(); System.out.println(p.num); // 输出 10前面第 2.4 节提过字段是按声明类型访问的不走动态分派。这里 p 的类型是 Parent所以 p.num 拿到的是 Parent 的 num10。很多人把这种情况误解为字段重写其实术语叫字段隐藏或者遮蔽Shadowing。要拿子类的 num必须向下转型成 Child 再访问。在实际业务代码里这种字段同名的情况尽量少用容易把人绕晕。6.3 静态方法没有重写class Parent { static void whoami() { System.out.println(Parent); } } class Child extends Parent { static void whoami() { System.out.println(Child); } } Parent p new Child(); p.whoami(); // 输出 Parent静态方法是类级别的通过引用调用静态方法时JVM 根据引用变量的声明类型直接定位不参与动态分派。你可以在子类中定义一个签名相同的静态方法但这不是重写而是隐藏Hide。所以这个例子输出 ParentChild.whoami() 只是把父类方法遮住了。顺便补充一个细节编译器对p.whoami()这种写法甚至会发出警告因为静态方法约定通过类名访问Parent.whoami()。写上p.whoami()容易给人造成这是多态的错觉其实根本没这事儿。6.4 重载与多态同时出现时的判定这是重载与多态的交叉考点class Animal {} class Dog extends Animal {} class Test { public void run(Animal a) { System.out.println(run Animal); } public void run(Dog d) { System.out.println(run Dog); } public static void main(String[] args) { Animal a new Dog(); new Test().run(a); // 输出什么 } }答案是run Animal。因为重载的选择发生在编译期编译期 a 的声明类型是 Animal所以编译器选择 run(Animal) 这个版本运行期的动态分派只负责在已经选定的方法版本内部找具体实现。这就是静态分派和动态分派的层次关系先按参数编译期选定重载版本再在版本内部动态分派。这类题目考察的其实是静态类型和动态类型在重载场景下的职责边界如果对编译看左边理解深刻这种题不会错。7. 设计模式里的多态从工厂到策略多态理解到位后最值的做的事情就是去看设计模式。我甚至觉得把设计模式当成多态的练习场来学比硬背模式定义效率高得多。这里挑三个最典型、也最容易在项目里直接使用的模式说。7.1 策略模式把算法族塞进同一个抽象假设你有一个支付系统需要对接支付宝、微信、银行卡三种支付方式。没有多态的世界里你会写一个巨大的 switch-casepublic void pay(String channel, double amount) { switch (channel) { case alipay: // 支付宝支付逻辑 case wechat: // 微信支付逻辑 case bank: // 银行卡支付逻辑 default: throw new IllegalArgumentException(); } }每次新增支付方式就要改这个方法。用多态 策略模式之后interface PaymentStrategy { void pay(double amount); } class AlipayStrategy implements PaymentStrategy { Override public void pay(double amount) { System.out.println(使用支付宝支付 amount); } } class WechatStrategy implements PaymentStrategy { Override public void pay(double amount) { System.out.println(使用微信支付 amount); } } public void pay(PaymentStrategy strategy, double amount) { strategy.pay(amount); }调用方只依赖 PaymentStrategy 接口支付方式的实现各自独立互不干扰。新增支付渠道就新增一个实现类不需要动原有代码。多态 策略模式的组合特别适合把变化的部分封装起来的场景。7.2 工厂模式面向接口创建对象再举一个常见例子。你有一段业务逻辑需要根据传入类型创建不同处理器。没有多态时你会写 if-else有工厂 多态后工厂负责创建对象调用方只和接口打交道。interface Handler { void handle(); } class OrderHandler implements Handler { Override public void handle() { /* 处理订单 */ } } class UserHandler implements Handler { Override public void handle() { /* 处理用户 */ } } class HandlerFactory { public static Handler create(String type) { if (order.equals(type)) { return new OrderHandler(); } else if (user.equals(type)) { return new UserHandler(); } throw new IllegalArgumentException(); } }虽然工厂内部仍然有 if-else但调用方的代码干净了而且未来新增 Handler 时改动点收敛在工厂这一个类里。这就是多态的价值把变化隔离起来让上层代码保持稳定。7.3 模板方法模式固定骨架延迟实现模板方法模式是多态在继承场景下的经典应用。它定义一个算法的骨架把其中可变的步骤留给子类实现abstract class DataParser { public final void parse() { readData(); process(); writeResult(); } protected void readData() { System.out.println(读取数据); } protected abstract void process(); protected void writeResult() { System.out.println(写出结果); } } class JsonParser extends DataParser { Override protected void process() { System.out.println(处理 JSON 数据); } } class XmlParser extends DataParser { Override protected void process() { System.out.println(处理 XML 数据); } }调用方只要 new 出对应子类parse() 的整体流程固定不同子类提供不同的 process 实现。这类代码在实际项目中到处都是读取配置、初始化流程、数据导入导出几乎都能用模板方法整理。7.4 项目中使用多态的实操建议最后给几条我自己写代码时的体会优先接口慎用抽象类。接口描述的是能做什么抽象类倾向是什么。在业务代码里能力边界比血缘关系重要得多。框架代码、工具类代码可以多用抽象类业务逻辑优先级要面向接口。方法参数尽量用接口类型。写一个方法时如果只需要某个能力就声明接口类型参数而不是具体实现类。这样调用方传什么进来都行你的方法通用性也更强。避免过深的继承层次。多态和继承是配套的但继承层次一旦超过三层代码就变得很难理解。能用组合就用组合能用接口就用接口。设计模式不要硬套。多态是为了解决变化的问题如果一段代码本身稳定、没有扩展需求强行抽象反而增加阅读成本。判断标准很简单你会不会在未来往这个方向加新的类型大概率会就做多态不太可能就别过度设计。Java 多态这个知识点表面上是面试八股实际是面向对象设计的基石。把它的运行机制和实战价值都吃透写代码时自然知道怎么拆分接口、怎么设计类结构面试时也不会被各种变体题目问倒。我自己每次重构代码回头看依赖最多的还是多态和接口这套思想——它真正的力量不是让代码跑起来而是让代码在变化来临的时候不用推倒重来。