Java 多态学习笔记(详细版)

1. 多态的定义与三要素

多态（Polymorphism）是面向对象编程的一项核心特性，它允许“同一个对象”在不同情境下表现出不同的形态和行为blog.csdn.net。简单来说，多态指的是同一类型的引用在程序运行过程中可以指向不同子类的实例，从而调用各自重写的方法，呈现出不同的执行效果worktile.com。要实现 Java 的运行时多态，通常需要满足三个要素：

1. 继承关系：类之间有继承（或接口实现）关系，提供了共同的父类或接口类型。

2. 方法重写：子类重写（Override）父类的实例方法，使得同一方法调用在不同类上有不同实现。

3. 父类（或接口）引用指向子类对象：通过将子类实例赋给父类类型的引用（即向上转型），以父类引用来调用重写的方法。

以上三点组合起来，才能体现出多态性。例如，有父类 Animal 和其子类 Dog，Dog 重写了 Animal 的实例方法 speak()。我们可以编写代码：

Animal a = new Dog(); // 父类引用指向子类对象 
a.speak(); // 调用的实际是 Dog 重写的 speak() 方法

在这个例子中，a 是静态类型为 Animal、动态类型为 Dog 的引用，最终执行的是子类 Dog 的 speak() 实现。这就是多态：同一个代码调用，在运行时因对象实际类型不同而执行不同的方法逻辑worktile.com。

值得注意的是，多态的目的是“统一调用接口，屏蔽差异”。通过让父类引用指向不同子类对象，可以编写出通用的代码逻辑。例如，“水果”作为父类概念，不管实际传入的是苹果还是西瓜，只要它们都是 Fruit 的子类，我们就可以用 Fruit 类型进行操作，而真正执行时会根据具体类型（苹果或西瓜）表现出不同行为。这种设计提高了代码的扩展性和灵活性。

2. 多态的表现：方法调用 vs 变量访问

Java 多态最直观的表现是在方法调用上，而属性（变量）访问并不具有多态性。具体来说：

• 方法调用的多态：当子类重写了父类的实例方法，通过父类引用调用该方法时，运行时会根据引用的实际对象类型来选择执行子类的实现。这就是动态方法分派（dynamic dispatch）。换句话说，调用哪个方法“看右边”（实际对象）。例如：

  Animal a = new Dog(); 
  a.speak(); // Dog 重写的 speak()

  即使变量声明类型是 Animal，因为实际对象是 Dog，调用时会执行 Dog 的 speak()dev.java。这种调用称为虚方法调用（virtual method invocation），是 Java 多态性的核心表现形式dev.java。

• 变量访问的静态性：与方法不同，成员变量不存在重写（override）的机制，不具备多态性stackoverflow.com。如果子类定义了一个与父类同名的变量（这称为隐藏而非重写），那么通过父类引用访问该变量时，只会访问父类版本的变量值stackoverflow.comstackoverflow.com。也就是说，属性取值“看左边”（引用的静态类型）。例如：

  class Animal { public String name = "Animal"; }
  class Dog extends Animal { public String name = "Dog"; }
  Animal a = new Dog();
  System.out.println(a.name);      // 输出 "Animal"
  System.out.println(((Dog)a).name); // 输出 "Dog"
  

  上述代码中，a.name 在编译期绑定到 Animal 的 name 字段，因此即使实际对象是 Dog，取到的还是父类 Animal 的 name（值为 "Animal"）。而强制转换为 Dog 后访问，则取到子类隐藏的字段（值为 "Dog"）。正如引用资料所说：Java 中没有针对字段的多态，变量的绑定在编译期就确定了，因此访问的总是编译时类型所定义的字段stackoverflow.com。

• 静态方法调用也类似于变量，不发生多态。静态方法属于类本身，不会被实例化对象重写。即便子类定义了同名的静态方法，这只是隐藏而非重写。通过父类引用调用静态方法时，执行的仍是父类类定义的方法，而不会动态绑定到子类实现softwareengineering.stackexchange.com。例如：

  class Animal { public static void printType() { System.out.println("Animal"); } }
  class Dog extends Animal { public static void printType() { System.out.println("Dog"); } }
  Animal a = new Dog();
  a.printType();   // 输出 "Animal" 而非 "Dog"
  Dog.printType(); // 输出 "Dog"
  

  可以看到，a.printType()执行的是父类的静态方法。这是因为调用静态方法实际上在编译阶段就决定了绑定到哪一个类。正如引用中所述：“调用静态方法总是执行声明该方法的类中的实现（没有多态），而调用实例方法则会执行实例类型重写后的方法（体现多态）”softwareengineering.stackexchange.com。

综上，对于实例方法，Java 在运行期根据实际对象类型动态选择方法实现；而对于字段和静态成员，访问在编译期就解析好了，与对象的实际类型无关softwareengineering.stackexchange.comstackoverflow.com。口诀“编译看左边，运行看右边”正是对这种现象的形象描述——左边指引用的编译时类型，右边指对象的运行时类型。但我们更应理解底层原因：方法调用采用动态分派，而变量访问和静态调用采用静态绑定。

3. 编译期 vs 运行期：静态类型与动态类型

要深入理解多态，需要区分编译期和运行期行为，以及静态类型和动态类型这两个概念：

• 静态类型（Static Type）：也称为编译时类型，指变量在源码中声明的类型。在编译阶段，Java 编译器根据静态类型进行语法检查、方法查找和绑定引用。例如在代码中写了 Animal a，那么在编译时编译器只知道 a 是 Animal，允许调用 Animal 类中定义的方法和属性（不包括子类特有的方法）。

• 动态类型（Dynamic Type）：也称为运行时类型，指变量实际引用对象的类型（在运行期间才确定）。比如 Animal a = new Dog();，a 的静态类型是 Animal，但动态类型是 Dog。运行时可以通过 a.getClass() 或类似机制得知动态类型。

编译期 vs 运行期：Java 程序在编译期确定了方法调用的静态绑定或重载解析，但对于重写的方法，真正的调用对象需要在运行期才能确定。这体现为：

• 编译期：依据静态类型进行静态分派。例如，方法重载(overloading)就是一种编译期多态，编译器根据参数静态类型选择合适的方法版本。这种选择在编译时完成，属于静态绑定wiyi.org。

• 运行期：涉及对象的实际类，进行动态分派。对于重写的方法调用，编译器虽然知道调用的是某个父类方法，但并不知道实际应执行哪一个子类的实现——这个过程在运行时由 JVM 根据对象的动态类型来决定wiyi.org。

换句话说，方法的选择存在两种阶段：

• 静态类型决定了可以调用哪些方法（编译期检查）；而

• 动态类型决定了实际调用哪个实现（运行期绑定）。

举个例子，假设有 Animal 类定义了 void eat(Food f) 重载了两个版本，以及 Dog 重写了其中一个版本。如果编译时调用代码是 a.eat(new Bone()) 而 a 静态类型是 Animal，那么编译器会根据 Animal 类中形参类型匹配来决定调用哪一个 eat 重载版本。而当实际执行时，如果 a 指向的是 Dog 对象且 Dog 对其中一个版本的 eat 方法有重写，那么JVM将在运行期调用 Dog 的实现wiyi.org。由此可见，静态类型限制了方法可见性和重载解析，而动态类型决定了重写方法的最终执行版本worktile.com。

另外，每个 Java 对象在运行时都会携带类型信息。在HotSpot JVM中，对象的头部包含一个指向其类元数据的指针，这个指针可以被视作对象的类型标识lukasatkinson.de。正是通过这个类指针，JVM 能在方法调用时确定对象的实际类型并据此动态分派到正确的方法实现。这也是为什么在运行期能够根据“右边”的实际类型来选择方法的根本原因。

总结：判断某段代码是否会表现出多态行为，可以从编译期和运行期两个角度分析。编译期检查变量的声明类型能否调用某方法；运行期则看对象实际类型的实现是否被调用。如果调用的是可被子类重写的实例方法，并且引用实际指向子类对象，那么调用绑定将推迟到运行期（动态绑定），体现多态。如果调用的是静态方法、私有方法、final 方法或访问字段，这些在编译期就完全确定（静态绑定），则不存在多态行为。

4. 字节码视角分析：invokevirtual、invokeinterface、getfield、invokestatic

Java 的多态特性在编译后的字节码指令层面也有清晰的体现。不同类型的调用和访问对应不同的字节码指令：

• invokevirtual：调用实例方法的指令。编译器用于普通的虚方法调用（非静态、非私有的实例方法）时，会生成 invokevirtual 指令wiyi.orgwiyi.org。例如，对象 a.speak() 会被编译为调用 Animal.speak 符号引用的 invokevirtual 指令。invokevirtual 的分派逻辑在JVM规范中定义了动态查找过程wiyi.orgwiyi.org：在执行时，JVM会取出对象引用 objectref 所属的实际类（动态类型）C，然后按照“如果类 C 覆盖了目标方法则调用覆盖后的方法，否则沿继承链向上查找”的规则寻找最终要执行的方法，实现动态分派wiyi.org。简单来说，invokevirtual 调用会根据对象实际类型在运行期选择合适的方法实现，这正是多态发生的地方wiyi.org。

• invokeinterface：调用接口方法的指令。当调用接口类型引用的方法时，编译器会生成 invokeinterface 指令。接口方法的分派稍有不同，因为一个类可以实现多个接口，不能像类继承那样直接通过单一的 vtable 下标定位。HotSpot JVM 对接口调用采用了接口方法表（itable）机制：在类的元数据中为每个接口维护一个方法表。invokeinterface 在运行时会根据接口的方法签名查找实现，通常实现为在对象类的 itable 列表中顺序查找匹配的接口及其方法实现lukasatkinson.de。找到匹配项后再调用相应方法。如果没有找到实现且接口方法无默认实现，则抛出 AbstractMethodError。由于需要搜索，比直接的虚方法表查找略慢，但现代 JVM 会通过内联缓存等优化技术加速接口调用lukasatkinson.de。总之，invokeinterface 实现了接口方法的动态分派（因为接口方法同样可能由不同实现类提供不同实现）。

• getfield：访问对象实例字段的指令。当代码读取对象的实例变量（非静态字段）时，会编译为 getfield 指令。与方法调用不同，字段没有动态分派：getfield 指令在链接阶段就解析绑定到特定类的特定字段符号stackoverflow.com。也就是说，编译器根据引用的静态类型确定要访问哪个类的哪个字段，生成类似 getfield Animal.name 这样的指令。运行时无论对象实际属于哪个子类，该指令都只会去对象内存布局中父类 Animal 部分的偏移读取 name 字段值。如果子类定义了同名字段，这只是隐藏而非覆盖——字节码仍然引用的是父类字段。因此，getfield 不具备多态性：字段访问在编译期就固定下来，由静态类型决定stackoverflow.com。

• invokestatic：调用静态方法的指令。静态方法属于类，在编译时即可确定调用目标，因此由 invokestatic 指令执行。比如 Animal.staticMethod() 会编译为 invokestatic Animal.staticMethod。即使写成 a.staticMethod()（其中 a 是 Animal 类型引用），编译器也知道这是调用静态方法，仍然生成对 Animal 类方法的 invokestatic 调用softwareengineering.stackexchange.com。静态方法没有动态分派，因为它不依赖于对象实例。invokestatic 在类首次使用时还会触发类的初始化（如果尚未初始化）。需要注意的是，Java 中静态方法是不能被重写的，如果子类定义了同名静态方法，调用时编译器会根据引用类型选择调用父类或子类的版本（实质是隐藏关系）。但无论如何，这种绑定都是在编译期完成的，调用过程不涉及运行期的类型判定softwareengineering.stackexchange.com。

此外还有 invokespecial 指令（用于调用实例初始化方法<init>、私有方法，以及使用 super 调用父类方法等特殊情况），它执行的是非虚方法调用，在编译期就能确定唯一目标。例如，调用私有方法和 final 方法时，编译器一般会选择 invokespecial 或内联处理，因为这些方法不能被覆盖，不需要动态分派。这一点在后续“特殊情况”部分会详细说明。

简而言之，Java 字节码层面对多态的支持体现为：可重写的实例方法使用 invokevirtual 或 invokeinterface 来实现动态绑定，而对于静态/私有/构造方法或字段访问则使用静态绑定的指令（invokestatic、invokespecial、getfield 等）来实现静态绑定blog.csdn.net。通过反编译字节码，我们可以直观地看到编译器针对不同情形选择的调用方式，从而验证哪些场景下发生了多态。

5. JVM 底层机制：vtable、itable、对象头与方法分派

了解了字节码层面的区别，我们再从 JVM 底层来看一下多态是如何实现的。HotSpot JVM 使用了类似 C++ 的虚函数表机制，但做了针对 Java 的优化blog.csdn.net：

• 虚方法表（vtable）：每个类在方法区都有一张虚方法表，用于支持动态分派。虚方法表是一个函数指针数组，包含了该类可以调用的所有实例方法的入口地址blog.csdn.net。具体来说，vtable 列出本类声明的实例方法（不包括静态方法和被声明为 final 的方法，它们不需要动态绑定）以及从父类继承而来的可覆盖方法blog.csdn.netblog.csdn.net。如果子类重写了某方法，那么它会在初始化类时替换掉继承自父类的那项表项为子类实现；如果子类新增了自己特有的实例方法，则追加在表的末尾blog.csdn.net。这样，vtable 保持了与父类相同的方法排列，对于相同签名的方法，子类和父类的表中位置相对应。这种结构保证了通过父类引用调用方法时，通过查询虚方法表可以在同一索引位置找到子类的实现，从而跳转执行。

  举个简单的例子blog.csdn.netblog.csdn.net：有类 A 定义方法 m1() 和 m2(String), 类 B 继承 A 并重写了 m1()，同时新增了 m3()。则 A 的虚方法表可能是：{ A.m1, A.m2 }；而 B 的虚方法表在继承 A 后会替换 m1 为 B.m1，保留 A.m2，并在末尾增加 B.m3，形成：{ B.m1, A.m2, B.m3 }。这样，通过 B 的实例调用第二个方法索引仍然会执行到 A 的 m2，而调用第一个方法索引会执行 B 自己的实现。虚方法表的作用是在方法调用时，通过对象找到它所属类的 vtable，再根据编译期确定的表索引直接取出目标方法入口，实现 O(1) 时间的动态方法调用。

• 接口方法表（itable）：接口的多态实现相比类继承更复杂一些。Java 单继承、多实现，一个类可能实现多个接口，每个接口有自己的一套方法。这在底层通过接口方法表来支持。HotSpot 为每个实现的接口在类的元数据（Klass）中维护一个 itable 列表lukasatkinson.de。itable 可以理解为“接口方法的虚方法表集合”。当使用接口引用调用方法时（invokeinterface），JVM 会在对象的类的 itable 列表中查找匹配的接口项，然后在对应接口的方法表中找到正确的方法实现指针lukasatkinson.de。HotSpot 的实现通常是线性地检查每个 itable 条目，比较接口标识直到找到目标接口，然后依据方法的索引获取实现lukasatkinson.de。虽然这种查找在最坏情况下是 O(n) 随实现的接口数增长，但由于一个类实现的接口通常有限，而且 JIT 编译器会针对频繁的接口调用使用**内联缓存（inline caching）**优化，将上次解析的结果缓存起来，通常可以将接口方法调用性能接近于普通虚方法调用lukasatkinson.de。

  值得一提的是，为了保证接口默认方法（Java 8 引入的 default 方法）也能正常分派，JVM 会将接口的默认实现纳入它的分派逻辑。如果一个类没有override某接口的默认方法，某些JVM实现会在类初始化时为其生成**“Miranda方法”**（一个桥接方法）放入该类的虚方法表或接口表，从而将调用分派到接口默认实现blog.csdn.net。不过具体细节因JVM实现而异，但对程序员来说，效果就是：接口默认方法如果未被重写，调用时会自动调用接口提供的默认实现，也表现出多态的效果（不同实现类调用结果可能不同：有的类用自己override的方法，有的用接口默认方法）。

• 对象头与 Klass Pointer：在 HotSpot JVM 中，每个对象实例的对象头都包含一个指向其类元数据的指针（称为 klass pointer）lukasatkinson.de。类元数据（Klass对象）中则保存了该类的字段、方法信息以及上述的 vtable 和 itable。这样，对象并不直接持有虚方法表，但可以通过自己的类指针间接获得。因此，当执行 invokevirtual 时，JVM取到对象头里的 klass 指针，定位到对应的类元数据，从中根据已解析的方法符号找到对应的 vtable 索引，再跳转到相应方法实现。由于所有相同类的对象共享一份类元数据和虚方法表，这种设计相比每个对象维护一张虚表更加节省内存blog.csdn.net（C++则是每个对象存有一个指向虚表的指针）。需要注意的是，这种通过对象找到类，再通过类找到方法实现的过程对程序员是透明的，但它正是支撑 Java 多态的底层机制blog.csdn.net。

• 方法分派过程：综合以上结构，当字节码执行 invokevirtual 或 invokeinterface 时，大致的底层过程是：

  1. 检索对象的 klass 指针，确定实际类型。

  2. 如果是 invokevirtual（调用的是类方法）：根据编译期解析到的方法在虚方法表中的索引，直接从该类的 vtable 中取出目标方法的入口地址并调用lukasatkinson.de。这是一次指针定位操作，开销很低。

  3. 如果是 invokeinterface（调用接口方法）：先在类的 itable 列表中按顺序找到对应的接口，然后按接口的方法索引从接口方法表（itable）中取出实现入口并调用lukasatkinson.de。如果搜索完整个列表未找到接口，则说明对象并不实现该接口，JVM 将抛出异常（这一情况正常编译的代码不会发生，因为类型检查已保证对象实现了接口）。

  4. JIT 优化：对于经常命中的调用，JIT 编译器会在调用现场插入缓存（例如记住上一次调用的目标类型和方法），下次调用时先快速检查对象类型是否与缓存匹配，如果是则直接跳转缓存的方法，实现内联缓存优化lukasatkinson.de。JIT 甚至可以在确定调用单一目标时将虚调用优化为直接调用或内联，从而完全消除分派开销。

通过上述机制，Java 在运行时实现了动态绑定：对于可重写的方法调用，不同类型对象会自动定位到各自合适的实现。而这些操作在大多数情况下只需常数时间完成（接口调用在第一次可能线性搜索，但后续可缓存）。虚方法表和接口方法表正是多态的底层支撑结构，它们将“根据实际类型调用方法”这一动态行为，高效地映射为表索引查找和指针跳转wiyi.org。理解了这一点，我们就明白了为什么静态方法和字段不需要进入这些表（它们不参与动态分派），而重写的方法必须通过这些表才能实现调用的晚绑定。

6. 多态中的特殊情况详解

在 Java 中，并非所有方法或成员都参与多态机制。这里我们总结几个特殊情况以及它们的处理方式，以加深对多态边界的理解：

静态方法与静态变量

静态方法属于类而非实例，因此不能被重写，只能在子类中重新声明（这叫方法隐藏）。调用静态方法时，绑定发生在编译期：编译器根据引用的静态类型决定调用哪一个类的静态方法softwareengineering.stackexchange.com。正如前文例子所示，Animal a = new Dog(); a.printType(); 实际执行的是 Animal.printType() 而非 Dog.printType()，哪怕 Dog 定义了同名静态方法。这种行为本质上不算多态，因为没有发生动态绑定——调用解析完全由编译器静态决定softwareengineering.stackexchange.comsoftwareengineering.stackexchange.com。Java 明确规定静态方法不受多态影响，为此甚至不允许给静态方法加 @Override 注解（会编译出错），提醒开发者这不是重写softwareengineering.stackexchange.com。

静态变量（类变量）类似地不参与多态。若父类和子类定义了同名的静态变量，也是发生隐藏而非重写。通过父类类型引用访问该变量时，只会得到父类类变量的值；通过子类访问则得到子类的值。这跟静态方法的规则一致：引用类型决定了访问哪个类的静态成员。例如：

class Animal { static String TYPE = "AnimalClass"; }
class Dog extends Animal { static String TYPE = "DogClass"; }
Animal a = new Dog();
System.out.println(a.TYPE);   // 输出 "AnimalClass"
System.out.println(Dog.TYPE); // 输出 "DogClass"

总而言之，静态成员（方法和变量）在多态性方面的原则是：始终引用所属类自身的实现或值，不会因为引用实际指向子类对象而改变。这也是因为静态成员在内存中只存在一份，存储在类本身的定义处，和具体对象无关softwareengineering.stackexchange.com。

final 方法与 final 变量

final 方法是被声明为不可重写的方法。由于子类不能覆盖它，所有对该方法的调用在运行时只会有唯一实现可选，因而不需要动态分派。尽管从字节码上看，对一个 final 实例方法的调用还是用 invokevirtual 指令，但实际上JVM可以做优化：因为确认没有子类实现，JIT 编译时可将其内联或当作非虚方法处理。这意味着在语义上，final 方法不体现多态（没有不同实现可切换），但它依然遵循实例调用的语法规则。例如：

class Animal { public final void run() { ... } }
class Dog extends Animal { /* 不能重写 run() */ }
Animal a = new Dog();
a.run();  // 只能调用 Animal 定义的 run() 实现

无论 a 指向什么子类，调用的都是父类 Animal 自己的实现。换句话说，final 方法将方法调用绑定提前到了编译期（或者说运行期仍是同一实现），排除了多态的一个变体。正因为如此，final 方法同样不会出现在虚方法表中（JVM在构建vtable时会跳过所有 final 方法blog.csdn.net），以减少不必要的动态查找。

final 变量指的是被声明为常量的变量。这里分两种情况：

• 对于 final 静态变量（尤其是编译期常量），编译器常会将其内联到使用处，这使得它在运行时甚至不需要通过变量名查找。因此谈不上多态性，所有类共享的静态常量在编译时就是固定值。

• 对于 final 实例变量，则表示该引用在对象构造后不再改变。但字段本身依然按照声明的类型访问，没有多态——final仅保证赋值不可变。需要强调的是，final 修饰符对变量的影响是限制可变性，而非绑定方式，所以和多态关系不大。只是由于 final 实例变量不能被子类修改，它在继承结构中相当于每个对象都有一份独立值，也不存在“覆盖”一说，更没有多态。

私有方法与私有变量

私有方法（private 方法）只在类内部可见，子类对其不可见也无法重写。如果父类和子类各自定义了同名的私有方法，它们只是恰巧名字相同，彼此之间没有继承关系。在编译层面，私有方法的调用会被编译为 invokespecial 指令，直接静态绑定到那个类的方法实现blog.csdn.net。这意味着调用私有方法从来不会走虚方法分派过程——在编译期目标就已确定。例如：

class Animal { private void secret() { System.out.println("Animal secret"); } public void test() { secret(); } }
class Dog extends Animal { private void secret() { System.out.println("Dog secret"); } }Animal a = new Dog();
a.test();  // 间接调用Animal.secret(), 输出 "Animal secret"

在上面代码中，Dog 定义了一个同名的 secret() 私有方法，但它并不覆盖 Animal 的 secret()。当 a.test() 调用父类的 test() 方法时，里面的 secret() 调用静态绑定到 Animal 的私有实现（因为 test()在Animal中，能访问的是Animal自己的private方法），因此输出仍是 "Animal secret"。子类的 secret() 根本没有机会参与。这证明了私有方法不参与多态：它既不继承给子类，也不在运行时动态选择。可以把私有方法视为隐含的 final——只是更严格，连子类都无法访问。由于这一性质，私有方法也不会占据虚方法表的槽位。

私有变量也是类似道理：子类无法直接访问父类的私有字段，更谈不上覆盖。同名的私有字段在父子类各自对象中独立存在，互不相关。而外部代码只能通过各自类的公有方法访问相应的私有字段（若提供的话）。因此，私有变量天然是封装在所属类内部的，不存在多态访问的问题。

接口默认方法 (default 方法) 的多态性

Java 8 引入的接口默认方法为接口提供了方法的实现。默认方法本质上还是实例方法，因此遵循接口的多态规则：

• 可以被实现类重写：如果实现类对某个默认方法提供了自己的实现，那么通过该接口引用调用时，会动态分派到实现类的覆盖方法，就像普通实例方法的多态调用一样。

• 也可以不重写，直接继承默认实现：如果实现类没有重写默认方法，那么调用该方法时将执行接口中定义的默认实现。这种情况下，虽然实现类没提供新实现，但从调用者角度看，不同类可能来自不同接口默认实现，也是一种多态行为。例如：

interface Pet { default void hello() { System.out.println("Pet hello"); } }
class Dog extends Animal implements Pet { /* 没有重写 Pet.hello() */ }
Pet p = new Dog();
p.hello();  // 输出 "Pet hello"

这里 Dog 未重写接口的默认方法，于是通过接口 Pet 引用调用 hello() 时，会执行接口中的默认实现。假如另外一个类 Cat 实现了 Pet 并override了 hello()，那么 Pet p = new Cat(); p.hello(); 将输出 Cat 自己的实现。可见，默认方法同样具备多态行为：接口引用在运行时会调用实际对象所属类对于该方法的实现——若有重写则用重写，没有则用接口默认。

需要注意冲突解析：如果一个类从多个接口继承了同名的默认方法（所谓“菱形继承”冲突），编译器会要求你在该类中显式覆写该方法，或者指定使用哪一个接口的默认实现（通过 InterfaceName.super.method() 调用）quora.com。因此，在最终的实现类中，每个默认方法要么被唯一确定的实现覆盖。对于调用者来说，仍然是按照接口引用的实际对象类型，调用对应的实现——只是此实现有可能是接口提供的默认代码。底层上，JVM 对这种情况做了支持（例如前述的 Miranda 方法技术），保证默认方法也通过接口方法表参与动态分派。所以可以认为：default 方法也是实例多态的一部分。

总结来说，接口默认方法并没有打破 Java 多态的既有模型，而是增强了接口的演化能力。对开发者而言，只需记住接口的默认方法可以被子类override，也会被动态绑定。当没有override时，接口的默认实现扮演了“父类方法”的角色，被继承下来参与运行期调用。

7. 示例代码与字节码分析

下面通过一个综合示例，将以上各点直观地展示，并使用 javap 反编译字节码验证多态行为：

**示例代码：**定义父类 Animal 和子类 Dog，以及接口 Pet，然后在主方法中通过不同引用类型进行调用。

// 父类
class Animal {public String name = "Animal";public static String type = "AnimalClass";public void speak() { System.out.println("Animal speaks"); }public static void staticMethod() { System.out.println("Animal staticMethod"); }public final void finalMethod() { System.out.println("Animal finalMethod"); }private void privateMethod() { System.out.println("Animal privateMethod"); }
}// 子类
class Dog extends Animal implements Pet {public String name = "Dog";                      // 隐藏父类namepublic static String type = "DogClass";          // 隐藏父类type@Overridepublic void speak() { System.out.println("Dog barks"); } // 重写实例方法public static void staticMethod() { System.out.println("Dog staticMethod"); } // 隐藏静态方法private void privateMethod() { System.out.println("Dog privateMethod"); }     // 定义同名私有方法（非重写）// finalMethod 无法重写，因为父类声明为final// 接口Pet的default方法hello()未重写，直接继承默认实现@Overridepublic void unique() { System.out.println("Dog unique"); }
}// 接口
interface Pet {default void hello() { System.out.println("Pet hello"); }  // 接口默认方法void unique();  // 抽象方法
}// 测试主类
public class TestPoly {public static void main(String[] args) {Animal a = new Dog();System.out.println("a.name = " + a.name);System.out.println("Animal.type = " + a.type);a.speak();a.finalMethod();a.staticMethod();// a.privateMethod(); // 编译错误，不能从外部调用私有方法Dog d = new Dog();System.out.println("d.name = " + d.name);System.out.println("Dog.type = " + Dog.type);d.speak();d.finalMethod();d.staticMethod();// d.privateMethod(); // 编译错误，同样无法直接调用Pet p = new Dog();p.hello();p.unique();}
}

预期输出：

a.name = Animal
Animal.type = AnimalClass
Dog barks
Animal finalMethod
Animal staticMethod
d.name = Dog
Dog.type = DogClass
Dog barks
Animal finalMethod
Dog staticMethod
Pet hello
Dog unique

请注意上述输出如何对应代码的多态和非多态行为：

• a.name 和 a.type 分别输出父类值 "Animal" 和 "AnimalClass"，证明字段和静态变量访问按静态类型处理，没有多态。

• a.speak() 输出 "Dog barks"，说明调用了子类重写的方法（多态发生）。

• a.finalMethod() 输出 "Animal finalMethod"，因为无法重写，调用父类实现。

• a.staticMethod() 输出 "Animal staticMethod"，静态方法按编译类型绑定。

• d.name、Dog.type 访问子类自身成员，输出 "Dog" 和 "DogClass"。

• d.speak() 输出 "Dog barks"（调用子类方法），d.finalMethod()仍是 "Animal finalMethod"，d.staticMethod() 输出 "Dog staticMethod"（通过类名调用子类静态方法）。

• p.hello() 输出 "Pet hello"（Dog 未重写接口默认方法，调用接口默认实现），p.unique() 输出 "Dog unique"（调用实现类对抽象方法的实现）。

**字节码分析：**使用 javap -c TestPoly 可以反编译上述 main 方法，关注关键指令（为简洁只摘取主要片段）：

// javap -c TestPoly.class 摘录
0: new        #1 <Dog>            // 创建 Dog 对象
5: astore_1                    // 存储到引用a
6: getstatic  #2 <Field java/lang/System.out:Ljava/io/PrintStream;>
9: aload_1
10: getfield   #3 <Field Animal.name:Ljava/lang/String;>      // 读取 a.name (Animal定义的)
13: invokevirtual #4 <Method java/io/PrintStream.println(Ljava/lang/String;)V>... 24: aload_1
25: invokevirtual #5 <Method Animal.speak()V>   // 调用 a.speak()，绑定到 Animal.speak
30: aload_1
31: invokevirtual #6 <Method Animal.finalMethod()V> // 调用 a.finalMethod() (final方法)
34: aload_1
35: invokestatic  #7 <Method Animal.staticMethod()V>   // 调用 Animal.staticMethod() (静态方法)...54: aload_2                  // aload_2 对应 Dog 类型引用 d
55: invokevirtual #5 <Method Animal.speak()V>   // 调用 d.speak(), 静态类型Animal
60: aload_2
61: invokevirtual #6 <Method Animal.finalMethod()V>   // 调用 d.finalMethod()
64: aload_2
65: invokestatic  #8 <Method Dog.staticMethod()V>     // 调用 Dog.staticMethod() (静态，已解析为Dog类)...78: aload_3                  // aload_3 对应接口 Pet 引用 p
79: invokeinterface #9 <Method Pet.hello()V> 1  // 接口调用 p.hello()
84: aload_3
85: invokeinterface #10 <Method Pet.unique()V> 1 // 接口调用 p.unique()

从上述字节码可以验证我们对多态机制的分析：

• 对于 a.speak() 和 d.speak()，字节码都是 invokevirtual Animal.speak，即在常量池引用父类 Animal.speak 方法符号wiyi.org。但运行时由于引用所指对象是 Dog，JVM 按 invokevirtual 规则找到 Dog 类的实现并执行wiyi.org。这体现了 invokevirtual 的动态分派。

• a.staticMethod() 调用被编译为对 Animal.staticMethod 的 invokestaticsoftwareengineering.stackexchange.com。不论对象实际是 Dog，此调用都直接绑定到 Animal 类的方法（执行结果验证了这一点），说明静态方法没有走虚调用。

• getfield Animal.name 用于读取 a.name，即使实际对象是 Dog，也只会取出 Animal 部分的 name 字段值stackoverflow.com。而对于 d.name（变量 d 是 Dog 类型），编译后会是 getfield Dog.name，取 Dog 自己的字段。

• 接口方法 p.hello() 和 p.unique() 编译成了 invokeinterface Pet.hello 和 invokeinterface Pet.unique 指令，对应接口的符号引用lukasatkinson.de。运行时，JVM 将通过 Dog 类实现的 itable 寻找 Pet 接口的实现方法：unique() 由 Dog 类实现（invokeinterface 调用到 Dog.unique）；hello() Dog 类未实现，则调用 Pet 接口默认方法实现。这体现了 invokeinterface 的动态分派行为。

通过代码和字节码的对照，我们可以清晰地看到哪些调用发生了多态（invokevirtual/invokeinterface 调用在运行期动态绑定到 Dog 实现），哪些是静态绑定（getfield 和 invokestatic 已在编译/链接时确定）。这种底层验证进一步加深了我们对 Java 多态工作原理的理解。

8. JDK 21 新特性：sealed 类对多态优化的影响

Java 17 引入了密封类和密封接口（sealed classes/interfaces），JDK 21 对其功能进一步完善。密封类允许在定义时显式列出哪些子类是被许可的，未列出的其他类无法继承该密封类。这一特性除了在建模上提供更严格的类型约束外，对多态的性能也有潜在益处。

性能优化：由于密封类的继承层次是封闭且已知的，JVM 在执行动态分派时可以利用这一信息进行优化。当调用密封类或接口的方法时，虚拟机知道实际可能出现的子类型集合是有限且固定的，这就为激进优化创造了条件moldstud.com。例如，JIT 编译器可以基于已知的子类集合使用**类层次分析（CHA）**来判断某调用点实际上只有一个可能的目标实现，或者即使有多个也在有限集合中。这样一来，JIT 可以选择将虚调用转化为更高效的直调用或内联，或者在运行时生成一个高效的分支跳转表，而不必每次按常规的vtable流程查找moldstud.com。

实际测试表明，在某些依赖多态调用的场景下，使用密封类型可以提升性能。例如，Oracle 的一份文章指出：“由于运行时知道了一组确定的子类，Java 虚拟机可以优化方法分派，在涉及多态调用的情况下获得更快的执行时间。最近的基准测试表明，使用密封类型在某些动态分派场景下性能提升可达约20%”moldstud.com。换句话说，sealed 类使得很多以前需要在运行时推断类型的工作提前成为已知，从而减少了动态分派的开销。

示例：假设有密封接口 sealed interface Shape permits Circle, Square { void draw(); }，只有 Circle 和 Square 两个实现。当我们用 Shape 引用调用 draw() 方法时，JIT 完全清楚可能的目标只有 Circle.draw 和 Square.draw 两个。它可以在机器码层面优化成类似：

if (shape instanceof Circle) { // 直接调用 Circle.draw 的实现 
} else { // 调用 Square.draw 的实现 
}

甚至可以进一步内联展开具体实现代码。这比起一般情况下通过vtable间接调用，节省了指针解引用开销和可能的分支预测成本。在大量调用的情况下，这种优化能带来显著性能收益。

需要强调的是，这种优化完全由 JVM 在幕后完成，对开发者是透明的。我们使用密封类的主要目的还是为了建模一个封闭的继承层次，提升代码的安全性和可读性。但作为额外福利，密封类也为 JVM 优化提供了更多静态信息。一些测试和资料表明，对于包含模式匹配和switch的代码，密封类也能让编译器在穷举检查和优化上做出改进，因为它知道不存在未知的子类分支。

综上，JDK 21 下密封类/接口对多态的影响体现在优化空间而非语义变化：多态的语义仍然保持不变，但已知封闭继承关系可使动态分派更加高效moldstud.com。这提醒我们，合理使用新特性不仅能改进设计，还可能获得性能上的回报。

9. 思维模型与总结：如何辨别多态行为

通过上述学习，我们对 Java 多态的使用方法和底层原理都有了深入理解。最后，总结一套分析思维模型，当遇到陌生情况时，可以用来判断其中是否涉及多态，以及应当如何处理：

1. 判断调用类型：首先区分这是在调用方法还是在访问属性/静态成员。如果是后者（如字段、静态方法），一般不涉及多态。如果是实例方法调用，则可能涉及多态。

2. 检查继承关系：看该方法或属性是否定义在父类/接口，并在子类中重写或隐藏。

   • 无继承或无重写：如果没有父子类关系，或方法在子类中不存在重写，那就不存在多态的情形，调用绑定是唯一的。

   • 存在重写：如果子类对父类的方法进行了重写，且调用时使用父类类型引用，那么这是多态的典型场景。

3. 分析修饰符：留意方法的修饰符：

   • static 静态方法：无法重写，不多态，调用绑定到编译期类型。

   • final 最终方法：不能被重写，因此也没有多态选择余地（但仍按实例方法语法调用，只是不会有别的实现）。

   • private 私有方法：不参与继承/重写，调用绑定在声明类，非多态。

   • 接口 default 方法：看实现类是否重写它，原则与普通实例方法一致，有无多态取决于是否被重写以及用哪种引用调用。

4. 引用类型 vs 对象类型：明确调用所用的引用变量的静态类型和其承载对象的实际类型。静态类型决定编译器采用哪种调用方式和检查哪些成员；实际类型决定运行时会执行哪个实现。如果二者不一致且存在可覆盖方法，那么多态调用大概率发生。例如，“父类类型引用指向子类对象并调用重写方法”就是经典的多态场景。

5. 字节码佐证（高级检查）：对于更加权威的验证，可以借助字节码指令判断：

   • 如果编译结果使用的是 invokevirtual 或 invokeinterface 指令，那么说明这个调用将在运行时动态分派，很可能是多态调用wiyi.org。

   • 如果使用的是 invokestatic 或 invokespecial，则调用目标在编译期/链接时就固定，不会有运行期多态。

   • 字段访问使用 getfield/putfield 则没有多态；相反，数组的多态性体现在数组元素的方法调用上，也可从指令上分析（不过数组本身没有方法重写问题）。

6. 联想规范和原理：回想JVM规范的规定：一般实例方法遵循“动态绑定”，静态/私有/final方法遵循“静态绑定”。可以将具体问题归类到这两种绑定之一，就能推断其行为。

举例来说，如果遇到“构造函数是否多态”“覆写 equals 方法如何工作”“枚举类型的方法覆盖”等问题，都可以套用以上思路。构造函数不是通过虚调用执行的（事实上构造对象时多态未发挥作用，因为对象尚未完全构造完成，就算调用super()也是静态绑定到确切的父类构造方法）。equals 方法是实例方法，若子类重写则通过多态调用，取决于引用实际类型。枚举类不能被继承，每个枚举成员本质上是 final，不存在多态等等。

最后，避免生搬硬套口诀：常见的口诀如“编译看左边，运行看右边”“方法重写看对象，属性访问看引用”等，确实凝练了多态行为，但只是现象总结。softwareengineering.stackexchange.com我们应该依靠对底层机制的理解去判断，而非仅靠记忆规则。通过本笔记对多态原理的学习，可以理解这些口诀背后的原因，从而在遇到复杂情况（如接口默认方法、多重继承冲突、泛型类型擦除对多态的影响等）时，能够推导出正确的结论。

总结：Java 多态让代码具有弹性和扩展力，但其实现并不神秘——靠的是编译器和JVM协同，通过方法表和类型信息在运行期替我们选好了方法。掌握了多态的“三要素”和背后的调用过程，我们就能更踏实地运用这一特性，写出可靠且优雅的面向对象代码，而不再迷信任何口诀。希望这份笔记能够帮助你真正理解并灵活运用 Java 的多态机制！