解决Spring Data JPA中接口默认方法覆盖失效问题

问题现象与分析

java 8引入了接口默认方法（default methods），允许接口在不破坏现有实现的情况下添加新方法，并提供默认实现。这在许多场景下都非常有用。然而，在spring data jpa等依赖aop代理的框架中，当接口定义了默认方法且其实现类对其进行了覆盖时，可能会出现意料之外的行为。

具体表现为：

1. 定义一个包含默认方法的接口，例如：

   public interface MyInterface extends Repository {
     default List findAll(H key) {
       System.out.println("Calling default method in MyInterface");
       return Collections.emptyList();
     }
   }

2. 创建一个实现类，并覆盖该默认方法：

   public class RepositoryImpl
       extends ACConcreateClassWhichImplementRepository implements MyInterface {
     @Override
     public List findAll(H key) {
       System.out.println("Calling overridden method in RepositoryImpl");
       // ... 实际业务逻辑 ...
       return findSome(key);
     }
     // 假设 findSome 是一个实际的业务逻辑方法
     protected List findSome(H key) {
         return Collections.emptyList();
     }
   }

3. 在Spring组件（如Controller）中，通过接口类型注入MyInterface的实例，并调用findAll方法：

   @Autowired
   private MyInterface myRepository;
   
   // 调用 myRepository.findAll(key)

   此时，预期应该执行RepositoryImpl中覆盖的findAll方法，但实际运行时却发现调用了MyInterface中的默认方法。

通过分析运行时堆栈跟踪，可以发现调用路径中包含了org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor，最终指向了接口的默认方法：

at com.MyInterface.findAll(MyInterface.java:12) // 接口默认方法被调用
at org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:86)
// ... 其他Spring AOP代理栈帧 ...

这与将接口方法定义为抽象方法时的行为形成鲜明对比。如果MyInterface中的findAll是抽象的，那么调用会正确地路由到RepositoryImpl中的实现：

at com.RepositoryImpl.findAll(RepositoryImpl.java:16) // 实现类方法被调用
// ... 其他Spring AOP代理栈帧 ...

这表明问题出在Spring AOP代理在处理接口默认方法时，其调度机制可能存在特殊性。

问题根源探究

Spring框架，特别是Spring Data JPA，广泛利用AOP（面向切面编程）来为Repository接口生成代理。这些代理负责拦截方法调用，并添加事务管理、查询执行、安全检查等横切关注点。当通过接口类型注入时，Spring通常会创建接口的代理实例。

对于Java 8的接口默认方法，Spring AOP代理机制在处理方法调用时，特别是像DefaultMethodInvokingMethodInterceptor这样的拦截器，可能存在一种内部逻辑。当代理方法被调用时，它需要决定是调用目标对象的具体实现方法，还是调用接口的默认方法。在某些特定情况下（可能与Spring Data JPA的内部机制结合），代理在解析方法时，可能优先将接口的默认方法视为一个“可直接执行”的逻辑，而未正确识别或优先处理实现类中对其的覆盖。

换句话说，当代理发现一个方法既有接口默认实现，又有实现类覆盖实现时，它可能未能正确地将调用分派给实现类的方法，而是错误地分派给了接口的默认方法。当接口方法是抽象的，代理没有其他选择，只能找到并调用实现类中的具体方法，因此不会出现此问题。默认方法的引入，为代理提供了一个“备选”或“直接”的执行路径，从而导致了这种意外行为。

Figma Slides

Figma Slides 是 Figma 发布的PPT制作和演示文稿生成工具，可以帮助创建、设计、定制和分享演示文稿

下载

解决方案

为了确保Spring AOP代理能够正确地调用实现类中被覆盖的方法，我们可以采取以下两种策略：

1. 使用 @Qualifier 注解明确指定 Bean

当存在多个实现类，或者Spring在解析接口默认方法时出现歧义，@Qualifier注解是解决此问题的标准方式。通过为实现类指定一个唯一的Bean名称，并在注入时使用@Qualifier引用该名称，可以明确告诉Spring应该注入哪个具体的实现。

示例代码：

首先，确保你的实现类被Spring容器扫描并注册为一个Bean。

// 接口定义（保持不变）
public interface MyInterface extends Repository {
  default List findAll(H key) {
    System.out.println("Calling default method in MyInterface");
    return Collections.emptyList();
  }
}

// 实现类 - 使用 @Service 或 @Component 注解，并可选地指定Bean名称
@Service("myRepositoryImpl") // 为实现类指定一个唯一的Bean名称
public class RepositoryImpl
    extends ACConcreateClassWhichImplementRepository implements MyInterface {

  @Override
  public List findAll(H key) {
    System.out.println("Calling overridden method in RepositoryImpl for key: " + key);
    // 假设 findSome 是一个实际的业务逻辑方法
    // return findSome(key);
    return Arrays.asList((T) ("Overridden Result for " + key)); // 示例返回
  }

  // 假设 ACConcreateClassWhichImplementRepository 提供了 findSome 方法
  protected List findSome(H key) {
      // ... actual implementation ...
      return Collections.emptyList();
  }
}

// 控制器或服务层，使用 @Qualifier 注入
@RestController
@RequestMapping("/api")
public class MyController {

    // 使用 @Qualifier 明确指定要注入的实现类Bean
    @Autowired
    @Qualifier("myRepositoryImpl") // 引用实现类定义的Bean名称
    private MyInterface myRepository; // 使用通配符简化泛型声明

    @GetMapping("/find/{key}")
    public List getResults(@PathVariable String key) {
        return myRepository.findAll(key);
    }
}

通过在@Autowired注解旁添加@Qualifier("myRepositoryImpl")，Spring将确保注入的是名为myRepositoryImpl的RepositoryImpl实例（或其代理），从而正确调用其覆盖的方法。

2. 直接按实现类类型注入

如果你的设计允许，并且你希望直接依赖于具体的实现类而非接口，那么可以直接将实现类类型注入到需要它的组件中。这种方法绕过了接口代理可能产生的歧义，直接引用了具体的实现Bean。

示例代码：

// 控制器或服务层，直接按实现类类型注入
@RestController
@RequestMapping("/api")
public class MyController {

    // 直接注入实现类类型
    @Autowired
    private RepositoryImpl myRepositoryImpl; // 使用通配符简化泛型声明

    @GetMapping("/find/{key}")
    public List getResults(@PathVariable String key) {
        return myRepositoryImpl.findAll(key);
    }
}

这种方式虽然解决了问题，但在某些追求“面向接口编程”的设计模式中可能不被推荐，因为它增加了对具体实现的耦合。然而，在特定场景下，它是一个简单有效的解决方案。

注意事项

• Bean 命名规范: 当使用@Component、@Service等注解时，如果没有明确指定名称，Spring会默认使用类名（首字母小写）作为Bean的名称。例如，RepositoryImpl的默认Bean名称是repositoryImpl。使用@Qualifier时，应与Bean的实际名称保持一致。
• 设计原则考量: 优先遵循“面向接口编程”的原则，提高代码的灵活性和可测试性。只有当遇到类似默认方法覆盖失效的问题时，才考虑使用@Qualifier或在特定场景下直接注入实现类。
• Spring 版本兼容性: 本文讨论的问题和解决方案基于Spring Boot 2.7.0和Spring Framework 5.3.21。在不同Spring版本中，AOP代理的行为可能略有差异，但@Qualifier的原理是通用的。
• AOP 代理机制: 深入理解Spring AOP的工作原理，特别是JDK动态代理和CGLIB代理的区别，以及它们如何处理方法调用和拦截，有助于更好地诊断和解决这类代理相关的复杂问题。

总结

在Spring Data JPA等依赖AOP代理的框架中，接口默认方法与实现类方法覆盖的交互有时会导致意外的行为，即在预期调用实现类覆盖方法时，却执行了接口的默认方法。这通常是由于Spring AOP代理在处理默认方法时的特定调度逻辑所致。

通过本文介绍的两种主要解决方案——利用@Qualifier注解明确指定要注入的Bean，或直接按实现类类型进行依赖注入——开发者可以有效地解决此问题，确保Spring容器能够正确地将方法调用路由到期望的实现逻辑。理解Spring的依赖注入和AOP机制对于构建健壮、可维护的企业级应用至关重要。