首先明确一个核心结论：当Java方法重载与重写同时出现在代码中时，JVM并不会陷入两难选择，更不存在所谓的“抉择”环节。它遵循一个非常清晰、独立的两阶段流程——编译期处理重载，运行期处理重写。二者形成完美的接力关系，互不干扰。
那么，具体是如何分工协作的呢？
编译期：只看变量的“表面身份”，确定方法签名
首先，Java编译器登场。它非常“势利眼”，只看代码中变量的声明类型（即编写代码时，在变量前面添加的那个类型），再根据传入参数的个数和类型，在当前作用域的所有同名方法中，找到最“匹配”的重载版本。这个选择过程在编译阶段就完成，一旦锁定，就会将调用指令（如 invokevirtual）连同具体的方法引用，一起写入字节码中。
- 举个例子：
Animal a = new Dog(); a.speak("hello");。编译器只会看a的“表面身份”——它是Animal类型的。然后，它会带着字符串参数"hello"，去Animal类及其父类中寻找所有名为speak、参数为String的方法。找到后，编译器就认定：调用目标就是Animal的这个签名。 - 至于返回值、异常声明等，它们完全不参与重载匹配的决策。
- 如果编译器在此阶段找不到合适的匹配，那么编译将直接报错。
运行期：看对象的“真实身份”，确定执行代码
编译期确定的，只是一个“该调用哪个方法名-参数组合”的签名。真正执行哪一段代码，还得看运行期。
当程序实际运行时，JVM会检查编译期锁定的那个方法签名，在对象真实的运行时类型中（例如 new Dog() 这个对象），是否被重写。它会沿着对象所属的类，从子类开始向上查找，优先使用子类中完全匹配的方法签名；如果子类没有重写，则继续向父类、祖类查找，直到找到第一个实现的版本。
- 这个过程依赖于
invokevirtual指令和虚方法表（vtable）这一经典机制。 - 注意，只有非 private、非 static、非 final 的实例方法才会被纳入动态分派的范畴。因为这些方法根本就不支持重写。
- 重写的定义非常严格：子类方法的签名（方法名 + 参数类型列表）必须与父类完全相同，否则最多算作子类新增的方法，而非重写。
关键之处：它们解决的是两个完全不同的问题
重载和重写，一个负责“选哪个门”，一个负责“门后谁在做事”，两者并非竞争关系，而是先后协作的关系，逻辑非常清晰：
- 第一步，编译器根据静态类型，将“该调用哪个重载签名”这个问题彻底锁定。
- 第二步，JVM在运行时，拿着这个锁定的签名，决定“这个签名对应继承链上哪个类中的具体实现”。
- 即使是子类一口气重写了父类的多个重载版本（例如同时重写了
speak()、speak(String)、speak(String, int)），每个版本在运行时也各自独立执行自己的动态分派流程，互不混合。
一个典型的例子，胜过千言万语
假设我们有这样的两个类：
class Animal { void speak() { } void speak(String s) { } }
class Dog extends Animal { @Override void speak() { System.out.println("Woof!"); } @Override void speak(String s) { System.out.println("Woof: " + s); } }
现在，我们执行这个调用：Animal a = new Dog(); a.speak("hi");，背后发生了什么？
→ 编译阶段：编译器根据 a 的声明类型 Animal 和参数类型 String，精准锁定了要调用的签名：Animal.speak(String)。它将该指令写入字节码。
→ 运行阶段：JVM发现当前对象 a 的实际类型是 Dog。于是它在 Dog 类中查找是否有 speak(String) 这个签名的方法。发现 Dog 确实重写了该方法，那么指令就会立即执行 Dog.speak(String) 中的代码，在控制台打印出 Woof: hi。
