本文深入解析 Java 方法引用（如 a::myTest）在实现函数式接口时，为何会调用接口默认方法而非类中重写的方法，并通过字节码语义与实例对比阐明其本质机制。
本文深入解析 java 方法引用（如 `a::mytest`）在实现函数式接口时，为何会调用接口默认方法而非类中重写的方法，并通过字节码语义与实例对比阐明其本质机制。
在 Java 中，方法引用是创建函数式接口实例的简洁方式，但其底层绑定逻辑常被误解。核心在于：方法引用 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(); // 注意：此处调用的是 this.myTest()
}
@Override
public void myTest() {
System.out.println("myTest class Method");
}
}当执行 MyIF my = a::myTest; 时，JVM 实际构建的是一个 MyIF 的匿名实现类实例，其等效逻辑如下：
MyIF my = new MyIF() {
@Override
public void init() {
a.myTest(); // ← 方法引用的目标：a::myTest 被映射至此处
}
// myTest() 仍沿用接口默认实现！未被重写
};因此，后续调用 my.myTest() 时：
立即学习“Java免费学习笔记（深入）”；
- my 是 MyIF 类型对象（非 A 类型），且未重写 myTest()；
- 根据 Java 接口默认方法解析规则，优先使用 MyIF.default myTest() → 输出 "myTest interface Method"。
而对比场景 MyIF my = new A(); 则完全不同：
- my 实际类型为 A，A 显式重写了 myTest()；
- 此时 my.myTest() 触发动态绑定（virtual dispatch），运行时选择 A.myTest() → 输出 "myTest class Method"。
✅ 关键结论总结：
- 方法引用 a::m 的目标始终是填充函数式接口的 抽象方法（SAM），与接口中是否存在同名默认/静态方法无关；
- 接口默认方法仅在实现类未提供具体实现时生效；方法引用生成的实例不继承实现类的非抽象方法，故 A 中的 myTest() 对该实例不可见；
- 若需让 myTest() 调用子类版本，必须确保该方法是 SAM（即删除 init()，改为 void myTest();），或改用 lambda 显式委托：MyIF my = () -> a.myTest();（此时 init() 被实现，但 myTest() 仍走默认）。
⚠️ 注意事项：
- 不要依赖方法名匹配来推断绑定关系——只看接口中哪个方法是 abstract；
- 使用 IDE 的 “Go to Implementation” 可能误导：它跳转的是引用声明处，而非运行时实际调用点；
- 编译器不会报错，但行为差异易引发隐蔽 bug，建议在复杂默认方法场景中优先使用显式 lambda 或重构接口设计。
理解这一机制，是写出可预测、可维护函数式代码的关键一步。
