本文详解当使用instance::method引用类中重写的方法来实现含默认方法的函数式接口时，为何实际调用的是接口默认实现而非类中重写版本，并通过代码对比阐明方法引用的目标绑定机制与动态分派规则。
本文详解当使用instance::method引用类中重写的方法来实现含默认方法的函数式接口时，为何实际调用的是接口默认实现而非类中重写版本，并通过代码对比阐明方法引用的目标绑定机制与动态分派规则。
在 Java 中，方法引用（如 a::myTest）用于简洁地实现函数式接口，但其行为高度依赖于接口的抽象方法签名与目标方法的语义匹配，而非表面名称一致。许多开发者误以为 a::myTest 会“代理”或“转发”到 A.myTest()，从而期望调用类中重写的版本；然而，真实逻辑是：方法引用始终绑定到函数式接口中唯一的抽象方法（SAM），而非同名的默认方法。
回顾示例代码：
@FunctionalInterface
interface MyIF {
void init(); // ← 唯一抽象方法（SAM）
default void myTest() {
System.out.println("myTest interface Method"); // ← 默认实现
}
}
class A implements MyIF {
@Override
public void init() {
myTest(); // 注意：此处调用的是当前对象的 myTest()
}
@Override
public void myTest() {
System.out.println("myTest class Method");
}
}当执行：
A a = new A(); MyIF my = a::myTest; // ✅ 关键：a::myTest 实现的是 init()，不是 myTest() my.myTest(); // → 输出 "myTest interface Method"
JVM 的解析过程如下：
立即学习“Java免费学习笔记（深入）”；
- MyIF 是函数式接口，仅有一个抽象方法 init()；
- a::myTest 表示“用 a.myTest() 作为 init() 方法的实现体”；
- 因此，my 实际等价于一个匿名内部类实例：
MyIF my = new MyIF() { @Override public void init() { a.myTest(); // ← 调用 A 实例 a 的 myTest()（正确！） } // myTest() 未被重写 → 继承接口默认实现 }; - 所以 my.myTest() 是对接口默认方法的直接调用，不涉及 A 的重写逻辑 —— 此处不存在动态绑定（virtual dispatch），因为 my 并非 A 类型，而是 MyIF 的新实现，且未覆写 myTest()。
反之，在显式实例化场景中：
MyIF my = new A(); // my 是 A 的实例，类型为 MyIF（但运行时是 A） my.myTest(); // → 输出 "myTest class Method"
此时 my 指向 A 对象，myTest() 调用触发 Java 的动态方法分派（dynamic dispatch）：JVM 查找运行时类型 A 中是否存在 myTest() 的重写版本，存在则优先调用 A.myTest()。
✅ 核心结论：
- 方法引用 obj::method 的目标是填充函数式接口的抽象方法，与接口中同名默认方法无关；
- 默认方法仅在未被实现类显式重写，且调用方类型声明为接口时，才可能被继承；
- 若想让 myTest() 调用类中版本，必须确保 my 的运行时对象真正实现了该方法（如 new A()），或显式在方法引用实现中覆写 myTest()（但需注意：函数式接口只允许一个抽象方法，无法用方法引用同时覆盖多个方法）。
⚠️ 注意事项：
- 不要依赖方法名相似性判断绑定逻辑，始终以 @FunctionalInterface 中的抽象方法为准；
- 若需组合行为（如既定制 init() 又复用类中 myTest()），应避免方法引用，改用 Lambda 或匿名类显式控制；
- 默认方法的设计初衷是向后兼容扩展接口，而非替代类继承机制；其可见性受引用类型静态声明严格约束。
掌握这一机制，可避免在 Stream API、事件处理器等高频使用方法引用的场景中出现隐蔽的行为偏差。
