Java接口多态调用基于运行时动态绑定，实际执行逻辑由对象真实类型决定；未重写的default方法会被调用；应避免instanceof长链判断，优先用策略模式或类型标识；泛型擦除后无法用于运行时分发。
接口引用指向不同实现类时，方法调用如何确定执行逻辑
Java 中的多态接口调用本质是运行时绑定（dynamic dispatch），不是编译期决定的。当你用 InterfaceType ref = new ConcreteImpl() 这种写法，ref.method() 调用的实际代码，取决于 ref 当前指向的对象真实类型，而不是声明类型。
关键点在于：接口本身不提供实现，JVM 会根据对象实际 class 查找该 class 中重写的对应方法字节码。哪怕多个实现类都实现了同一个接口方法，只要它们各自有独立的 public void method() 实现，就会走各自的逻辑。
- 编译时只检查
ref声明类型是否定义了该方法（即接口中是否有该方法签名） - 运行时忽略接口声明，直接查对象实例的 runtime class 的 vtable（虚方法表）
- 如果实现类没重写接口默认方法（Java 8+），则回退到接口中的
default实现
使用 default 方法时，子类未重写会触发什么行为
接口里的 default 方法是为向后兼容引入的，它允许在不破坏已有实现类的前提下扩展接口。但它的调用优先级低于实现类中显式定义的方法。
interface Animal {
default void speak() {
System.out.println("Some sound");
}
}
class Dog implements Animal {
// 没重写 speak()
}
class Cat implements Animal {
@Override
public void speak() {
System.out.println("Meow");
}
}
此时：
立即学习“Java免费学习笔记（深入）”；
-
new Dog().speak()→ 输出"Some sound" -
new Cat().speak()→ 输出"Meow" - 若某实现类同时继承父类并实现接口，且父类和接口都有同签名方法，则父类方法优先（接口
default不参与继承链竞争）
当接口有多个实现类，如何安全地做运行时类型区分与分支处理
纯接口多态本意是“对同一操作隐藏差异”，但现实开发中常需根据具体实现做差异化处理（比如日志、监控、降级）。这时要避免滥用 instanceof 破坏封装，优先考虑设计优化；若必须区分，注意以下几点：
- 不要用
if (obj instanceof Dog) { ... } else if (obj instanceof Cat) { ... }做长链判断——一旦新增实现类就得改这里，违反开闭原则 - 可让每个实现类自行返回类型标识（如枚举
getType()），或提供策略识别方法（如supports(Feature)） - 若涉及外部系统适配（如不同支付渠道），建议用工厂 + 策略模式组合，把
instanceof限制在工厂内部 - 反射调用
getClass().getSimpleName()属于兜底手段，性能低且易受混淆/重命名影响
泛型接口配合多态时，类型擦除如何影响实际调用
泛型接口（如 Repository<T>）在运行时已无 T 具体信息，所以不能靠泛型参数做多态分发。下面这种写法不会按 T 类型走不同逻辑：
interface Repository<T> {
void save(T obj);
}
class UserRepo implements Repository<User> {
public void save(User u) { ... }
}
class OrderRepo implements Repository<Order> {
public void save(Order o) { ... }
}
问题在于：
- JVM 中两个
save方法签名都是save(Object)（类型擦除后），无法构成重载 - 即便你试图在调用侧写
repo.save(user)，实际绑定仍只看repo的运行时类型，和泛型参数无关 - 若需基于数据类型路由，得额外传入
Class<T>或用getType()辅助判断
泛型真正起作用的地方是编译期类型检查和 IDE 提示，不是运行时多态的依据。
