先说一个核心结论：当重载与重写同时在Ja va代码里出现时，JVM并不会陷入两难境地，更没有所谓的“抉择”环节。它遵循的是一个非常清晰、独立的两步走流程——编译期处理重载，运行期处理重写。二者是完美的接力关系，互不干扰。
那么，具体是怎么分工的呢？
编译期：只看变量的“表面身份”，确定方法签名
首先，Ja va编译器登场。它非常“势利眼”，只看你代码里那个变量的声明类型（也就是你写代码时，在变量前面加上去的那个类型），再根据你传入参数的个数和类型，在当前作用域的所有同名方法里，找到一个“最匹配”的重载版本。这个选择过程在编译阶段就完成了，一旦锁定，就会把调用指令（比如 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。
