Java 不支持基于参数实际类型（runtime type）的多分派（multiple dispatch），方法重载的解析完全由编译器依据静态类型（compile-time type）决定，因此 mapper.map(a)（其中 a 的静态类型为 I）无法匹配 map(A) 或 map(B)，即使 a 实际是 A 的实例。

java 不支持基于参数实际类型（runtime type）的多分派（multiple dispatch），方法重载的解析完全由编译器依据静态类型（compile-time type）决定，因此 `mapper.map(a)`（其中 `a` 的静态类型为 `i`）无法匹配 `map(a)` 或 `map(b)`，即使 `a` 实际是 `a` 的实例。

Java 的方法调用机制严格区分 重载（overloading） 和 重写（overriding）：

• 重写 是运行时行为，依赖于接收者（receiver）的动态类型，即单分派（single dispatch）——JVM 根据 this 的实际类型选择最终执行的方法；
• 重载 则是编译时行为，仅依据所有参数的声明类型（静态类型） 确定目标方法签名，与运行时对象的真实类型无关。

这解释了你代码中的编译错误：

I a = new A();  // 静态类型是 I，动态类型是 A
mapper.map(a);  // 编译器只看到参数类型 I，而 C 接口中无 map(I) 方法

尽管 a 实际是 A，但编译器无法（也不被设计为）在运行时根据 a.getClass() == A.class 去“重新选择” map(A)。它只检查接口 C 是否声明了接受 I 类型参数的 map 方法——而你只定义了 map(A) 和 map(B)，二者均不能通过向上转型自动接受 I（因为 Java 重载不考虑子类型关系的隐式适配）。

为什么 Java 选择编译期重载解析？

这不是技术限制，而是经过权衡的设计决策：

java-enterprise

Java企业开发专家，专注于Spring Boot、微服务架构和JVM优化。适用于：Java语言掌握、

下载

立即学习“Java免费学习笔记（深入）”；

✅ 可预测性与可维护性
每个方法调用站点（call site）在编译后绑定到唯一确定的方法签名，开发者无需追踪运行时类型组合即可理解控制流。

✅ 类型安全前置
若将重载解析推迟到运行时，可能遇到“无最优候选”的歧义场景（例如：I x = new C();，而 C 同时实现 A 和 B，且 map(A) 与 map(B) 均适用），此时只能抛出 IncompatibleClassChangeError 或类似异常——这违背了 Java “失败早、失败明”的设计哲学。

✅ 性能与实现简洁性
编译期解析只需一次类型推导，避免每次调用都执行复杂的最具体方法（most specific method）判定。同时，它大幅简化了虚拟机指令集（如 invokeinterface / invokevirtual 无需扩展以支持多参数分派逻辑）。

✅ 避免重载与继承的语义冲突
设想子类重写了父类中某个重载方法，又新增了更具体的重载版本：若支持运行时多分派，需额外定义“跨继承层次的最具体性规则”，极易引发反直觉行为（如子类新增的 map(A) 反而不如父类的 map(I) 被选中）。

替代方案：如何实现类似多分派的效果？

1. Visitor 模式（推荐）
   将分派逻辑显式委托给被访问对象：

   interface I {
       <R> R accept(IVisitor<R> visitor);
   }
   interface IVisitor<R> {
       R visit(A a);
       R visit(B b);
   }
   static class A implements I {
       @Override public <R> R accept(IVisitor<R> v) { return v.visit(this); }
   }
   // 使用时：
   String result = ((I) new A()).accept(new IVisitor<>() {
       public String visit(A a) { return "a"; }
       public String visit(B b) { return "b"; }
   });

2. 使用 instanceof + 显式分支（简单场景）

   String map(I i) {
       if (i instanceof A a) return map(a);
       if (i instanceof B b) return map(b);
       throw new IllegalArgumentException("Unsupported type: " + i.getClass());
   }

3. Sealed 类型 + switch 表达式（Java 17+）
   若 I 是 sealed interface I permits A, B，可安全穷举：

   String map(I i) {
       return switch (i) {
           case A a -> map(a);
           case B b -> map(b);
           default -> throw new IllegalStateException("Unexpected value: " + i);
       };
   }

⚠️ 注意：sealed 本身不改变重载机制，它只是让编译器能验证 switch 覆盖全部子类型，从而提升分支安全性——真正的分派逻辑仍需手动编写或借助 Visitor。

总之，Java 放弃运行时多分派并非疏忽，而是以牺牲少量表达力为代价，换取了更强的可推理性、健壮性和工程可控性。这一设计在绝大多数企业级应用场景中已被证明是务实且高效的选择。