作者：张葛  职位：后端工程师

一、前言

从我们进⼊编程的世界，成为程序员到现在为⽌，总有⼏个感觉神奇和激动的时刻，其中肯定包括你第⼀次程序连上数据库可以实现 CURD 功能的时候，就算那时的我们写着千遍⼀律 JDBC 模板代码也是乐此不疲。

时代在不断进步，技术也不断在发展，市面上已经有很多优秀的数据库持久化框架供我们使用，今天我将带大家来了解JPA的使用。

二、基本使用

在我们现在Spring Boot横行无忌的时代，在项目中引入JPA非常简单，我们以Maven以及常用的MySQL数据库为例

在pom.xml文件添加以下依赖

1. <parent>

2. <groupId>org.springframework.boot</groupId>

3. <artifactId>spring-boot-starter-parent</artifactId>

4. <version>2.5.6</version>

5. <relativePath/>

6. </parent>

7.  

8. <!-- jpa -->

9. <dependency>

10. <groupId>org.springframework.boot</groupId>

11. <artifactId>spring-boot-starter-data-jpa</artifactId>

12. </dependency>

13. <!-- mysql -->

14. <dependency>

15. <groupId>mysql</groupId>

16. <artifactId>mysql-connector-java</artifactId>

17. </dependency>

在Spring Boot的YML文件中添加以下内容

1. spring:
2. datasource:
3. driver-class-name:
4. com.mysql.cj.jdbc.Driver
5. url:jdbc:mysql://localhost:3306/sakila?useUnicode=true&zeroDateTimeBehavior=convertToNull&autoReconnect=true&characterEncoding=utf-8 username: root
6. password: root

定义Entity类，我测试过程使用的数据源为MySQL官方提供的样例数据库sakila，大家可以在https://dev.mysql.com/doc/index-other.html自行下载

1. @Entity
2. @Data // lombok注解
3. public class Actor {
4. 

5.  @Id
6.  // Column注解不是必须的，如果满足字段驼峰形式
7.  // 与数据库字段以下划线分隔形式对应即可
8.  @Column(name = "actor_id", nullable = false)
9.  private Integer actorId;
10.  
11.  @Column(name = "first_name", nullable = false, length = 45)
12.  private String firstName;
13.  private String lastName;
14.  private Timestamp lastUpdate;
15. }

定义Respository接口，一般我们通过继承JpaRepository接口即能满足我们一般的CURD操作，如果需要支持复杂逻辑查询

比如：动态SQL；联表查询，则需要继承 JpaSpecificationExecutor 接口，并配合Specification的接口方法。

1. @Repository

2. public interface ActorRepository extends JpaRepository<Actor, Integer> {

3. }

在JpaRepository的中我们可以看到有findAll、getById、findById、save、saveAll、deleteById...这些默认定义，这是JPA为我们提供的常用的一些数据操作，我们可以直接使用，极大提高了日常的开发效率。

2.1通过方法名称直接生成查询

正是因为这一便利的让人着迷的特性，让我们乐于去使用JPA这一持久化框架，接下来让我们通过几个例子去欣赏它的迷人之处吧。

2.1.1一般写法

1. /**

2.  * 示例1

3.  * SQL: SELECT * FROM actor WHERE first_name = ?

4.  * 参数名的定义不影响程序的运行

5.  */

6. List<Actor> findByFirstName(String name);

7.  

8. /**

9.  * 示例2

10.  * SQL: SELECT * FROM actor WHERE first_name = ? AND last_name = ?

11.  * 如果明确知道查询结果返回唯一一条记录时，建议使用单一实体类作为返回类型

12.  */

13. List<Actor> findByFirstNameAndLastName(String name1, String name2);

14.  

15. /**

16.  * 示例3

17.  * SQL: SELECT * FROM actor WHERE actor_id <= ?

18.  */

19. List<Actor>findByActorIdLessThanEqual(Integer id);

遵照JPA的规范，通过定义类似以上接口方法的形式就可以零SQL实现我们需要的单表查询(不能实现DML操作)操作。JPA对此类查询方式有很丰富的支持，受限于篇幅，我们就不一一讲述了，详细的内容可以阅读官方文档

地址：

https://docs.spring.io/spring-data/jpa/docs/2.5.6/reference/html/#repository-query-keywords

Tips

1.在查询场景中，自定义的查询接口中，find关键词（也可以是search、query、get）后面必须跟随By关键词

2.Between适用于数值、日期字段，用于日期时，参数类型可以是java.util.Date或java.sql.Timestamp

• List<Film> findByLengthBetween(Integer low, Integer up);
• List<Film> findByLastUpdateBetween(Date startDate, Date endDate);

3.IsEmpty / IsNotEmpty只能用于集合类型的字段

4.Before或者After可用于日期、数值类型的字段

• List<Film> findByLengthBefore(Integer length)

5.涉及到删除和修改时，需要在方法定义上加上@Modifying

2.2基于@Query 注解的操作

2.2.1使用JPQL

JPQL是通过Hibernate的HQL演变过来的，它和HQL语法及其相似。

1. /**
2.  * 示例1
3.  * SQL: SELECT * FROM actor WHERE first_name = ?
4.  */
5. @Query("FROM Actor WHERE firstName = ?1")
6. List<Actor> findByFirstName(String name);

7.  
8. /**
9.  * 示例2
10.  * SQL: SELECT * FROM actor WHERE first_name = ? AND last_name = ?
11.  */
12. @Query("FROM Actor WHERE firstName = ?1 AND lastName = ?2")
13. List<Actor> findByFirstNameAndLastName(String name1, String name2);
14.  
15. /**
16.  * 示例3
17.  * SQL: SELECT * FROM actor WHERE actor_id <= ?
18.  */
19. @Query("FROM Actor WHERE actorId <= ?1")
20. List<Actor> findByActorIdLessThanEqual(Integer id);

21.  
22. /**
23.  * 示例4
24.  * SQL: SELECT * FROM actor
25.  * 不能写"SELECT *" 要写"SELECT 别名"
26.  */
27. @Query("SELECT a FROM Actor a")
28. List<Actor> findAll()

通过以上例子我们发现，JPQL与SQL的区别是，SQL是面向对象关系数据库，它操作的是数据表和数据列，而JPQL操作的对象是实体对象和实体属性，区分大小写，出现的SQL关键字还是原有的意思，不区分大小写。JPQL也可以支持复杂的联表查询。下面是JPQL的基本格式：

看完查询的写法，我们来看看DML操作的写法

2.2.2使用原生SQL

在Query注解中，有一个属性字段nativeQuery，默认情况下为false，即为JPQL模式，如果我们设置为true，则我们可以value属性中定义原生SQL语句实现数据库操作。

1. @Query("SELECT * FROM actor WHERE first_name = ?1", nativeQuery = true)

2. List<Actor> findByFirstName(String name);


3.  

4. @Query("SELECT * FROM actor WHERE first_name = ?1 AND last_name = ?2", nativeQuery = true)

5. List<Actor> findByFirstNameAndLastName(String name1, String name2);


6.  

7. @Query("SELECT * FROM actor WHERE actor_id <= ?", nativeQuery = true)

8. List<Actor> findByActorIdLessThanEqual(Integer id);

9.  

10. @Query("SELECT first_name, last_name FROM actor", nativeQuery = true)

11. List<Map<String, Object>> findAll();

12. // List<String[]> findAll();

通过上述示例，我们总结几点编写原生SQL需要注意的地方

1.如果接口方法返回的是实体对象，如List<Actor>、Actor这样的，则SELECT部分不能指定字段名，必须为*

2.如果只想查询指定列的数据，方法定义时的返回类型可以是Map<String, Object>、String[]，返回数据如果是多条，则用集合类嵌套

3.关于JPA接口方法的返回类型我们可以参考官方文档，地址为：

https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repository-query-return-types

三、JPA的原理浅析

通过前面的学习，我们已经对JPA有了比较清晰的了解，不再是门外汉了，当然我们还是会有很多的疑问：

○为什么我们只是加入了一个Maven的依赖，就能直接使用JPA?

○为什么我们只是定义了一个Repository的接口就能直接使用它来实现数据库操作逻辑？

○为什么我们只是按照JPA的规范，定义了一个接口方法就能在使用时生成想要的SQL？

在接下来的学习中一一解开。

3.1JPA的自动配置

虽然这一节是要讲JPA的自动配置，其实本质要说的是Spring Boot自动加载配置的原理。在我们使用Spring Boot创建一个项目时，必不可少的一个注解就是@SpringBootApplication，看着它我们既熟悉又陌生。我们通过它的源码来一探究竟。

1. package org.springframework.boot.autoconfigure;


2.  

3. @Target(ElementType.TYPE)

4. @Retention(RetentionPolicy.RUNTIME)

5. @Documented

6. @Inherited

7. @SpringBootConfiguration

8. @EnableAutoConfiguration

9. @ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),

10.   @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })

11. public @interface SpringBootApplication {

12. 


13.  @AliasFor(annotation = EnableAutoConfiguration.class)

14.  Class<?>[] exclude() default {};


15.  

16.  @AliasFor(annotation = EnableAutoConfiguration.class)

17.  String[] excludeName() default {};


18.  

19.  @AliasFor(annotation = ComponentScan.class, attribute = "basePackages")

20.  String[] scanBasePackages() default {};


21.  

22.  @AliasFor(annotation = ComponentScan.class, attribute = "basePackageClasses")

23.  Class<?>[] scanBasePackageClasses() default {};


24.  

25.  @AliasFor(annotation = ComponentScan.class, attribute = "nameGenerator")

26.  Class<? extends BeanNameGenerator> nameGenerator() default BeanNameGenerator.class;


27.  

28.  @AliasFor(annotation = Configuration.class)

29.  boolean proxyBeanMethods() default true;


30.  

31. }

通过源码我们发现其实SpringBootApplication也被一些注解所修饰，其中就有EnableAutoConfiguration注解，一看名字我们就知道它就是我们今天要找的正主。同样的，我们也不会放过它的源码的。

1. package org.springframework.boot.autoconfigure;


2.  

3. @Target(ElementType.TYPE)

4. @Retention(RetentionPolicy.RUNTIME)

5. @Documented

6. @Inherited

7. @AutoConfigurationPackage

8. @Import(AutoConfigurationImportSelector.class)

9. public @interface EnableAutoConfiguration {


10.  

11.  String ENABLED_OVERRIDE_PROPERTY = "spring.boot.enableautoconfiguration";

12. 


13.  Class<?>[] exclude() default {};

14. 


15.  String[] excludeName() default {};

16.  

17. }

    
    

我们又看到了熟悉的身影，@Import注解，它意味着在我们的IOC容器中引入一个AutoConfigurationImportSelector对象。

通过源码我们又发现AutoConfigurationImportSelector最终实现了ImportSelector接口。因此在程序的启动过程中，会执行selectImports方法，在当前的实现中，这个方法的主要逻辑是去读取一个 spring.factories下key为EnableAutoConfiguration对应的全限定名的值。

spring.factories里面配置的那些类，主要作用是告诉 Spring Boot这个stareter所需要加载哪些xxxAutoConfiguration类，也就是你真正的要自动注册的那些bean或功能。

而在SpringBoot中的META-INF/spring.factories（完整路径：spring-boot/spring-boot-autoconfigure/src/main/resources/META-INF/spring.factories）中关于EnableAutoConfiguration的这段配置如下 ：

可以发现有JpaRepositoriesAutoConfiguration和HibernateJpaAutoConfiguration帮我们配置了JPA 相关的配置。至此，我们的第一个疑惑可以解开了。

3.2 SimpleJpaRepository类

接下来我们要来解决第二个疑惑，其实本节的标题已经告诉了我们答案。先上源码：

1. @Repository

2. @Transactional(readOnly = true)

3. public class SimpleJpaRepository<T, ID> implements JpaRepositoryImplementation<T, ID> {

4. }

我们不用看具体实现的方法逻辑了，单从SimpleJpaRepository的声明来看，它是一个类，不是抽象类是一个实现了JpaRepositoryImplementation接口的类

实际上JpaRepositoryImplementation接口也继承了JpaRepository和JpaSpecificationExecutor接口。

到此，我们可以大胆的猜测，为什么我们定义的repository接口只是继承了JpaRepository和JpaSpecificationExecutor接口就能使用一系列的接口调用，其实是SimpleJpaRepository类帮我们做了要做的事情。

那到底是不是，如果是的，那JPA是怎么做到了的呢？我们继续一步一步分析。首先我们得有一个分析的起点，上一节我们讲了JPA的自动配置，那我们是不是需要看看它到底配置了什么，看看能不能找到我们想要的。我们直接看JpaRepositoriesAutoConfiguration，因为它的名字里带Repositories。

我们好像运气不错，果然发现有一个Import注解引入了一个JpaRepositoriesRegistrar类，从名字看，JPA repository注册器，好像越来越接近了，直接上源码：

1. class JpaRepositoriesRegistrar extends AbstractRepositoryConfigurationSourceSupport {

2. }


3.  

4. public abstract class AbstractRepositoryConfigurationSourceSupport

5.   implements ImportBeanDefinitionRegistrar, BeanFactoryAware, ResourceLoaderAware, EnvironmentAware {


6.  

7.  private ResourceLoader resourceLoader;


8.  

9.  private BeanFactory beanFactory;


10.  

11.  private Environment environment;


12.  

13.  @Override

14.   public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry,

15.  BeanNameGenerator importBeanNameGenerator) {

16.   RepositoryConfigurationDelegate delegate = new RepositoryConfigurationDelegate(

17.   getConfigurationSource(registry, importBeanNameGenerator), this.resourceLoader, this.environment);

18.   delegate.registerRepositoriesIn(registry, getRepositoryConfigurationExtension());

19. }

20. 


21. @Override

22. public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {

23. registerBeanDefinitions(importingClassMetadata, registry, null);

24. }

25. 


26.  // 其他源码

27.   ...

28. }

其实分析了这么久，如果我们经常去看看Spring系的一些源码，会发现很多老朋友。我们看到其中一个关键接口ImportBeanDefinitionRegistrar，它的关键方法就是registerBeanDefinitions了，就是按照我们的实现逻辑把一些我们需要的bean注册到IOC容器中。分析到这，我们通过测试代码调试来看看吧。

我们可以看到debug窗口中，在测试类中注入的CustomerRepository接口的实际对象是JdkDynamicAopProxy类型，这是一个jdk动态代理类，这确实比较符合我们对Spring IOC容器对接口类注入处理的认识。我们看一下它代理的目标类，发现是SimpleJpaRepository类，如此就证实了我们之前的猜测。第一次调试到此结束。

我们再回过头来看我们之前找到的AbstractRepositoryConfigurationSourceSupport类中registerBeanDefinitions方法，这个是在项目启动过程中执行的，我们加上断点进行第二次调试。

registerBeanDefinitions方法中主要的逻辑在delegate.registerRepositoriesIn中实现，我们直接在里面标记上断点。

当执行到上面断点后，我们看到configurations对象中已经有了我们自己定义的repository接口的信息了，接下来我们将进入for循环分别处理我们定义的接口了，我们进到下一个断点继续看。

在当前断点，我们可以看到，beanName是符合我们正常创建IOC容器中bean的命名规则的，但是JPA为我们创建的BeanDefinition对象是org.springframework.data.jpa.repository.support.JpaRepositoryFactoryBean类型，它是一个FactoryBean。我们继续看187、189行的代码

JPA将我们的BeanDefinition对象设置了一个name为factoryBeanObjectType，value为当前被处理的repository接口的全限定类名（比如ai.advance.jpademo.repository.FilmRepository）的attribute

最后将BeanDefinition对象注册到了我们的IOC容器中。因此当for循环执行完后，如果我们使用repository接口对应的beanName从IOC容器中获取一个实例，最开始我们拿到的是一个JpaRepositoryFactoryBean类型的Bean，当然我们最后真正拿到的bean对象是由getObject方法返回的对象。我们先来看一下它的继承关系：

JpaRepositoryFactoryBean既是一个工厂，又是一个bean。其作用类似于@Bean注解，但比其能实现更多复杂的功能，可以对对象增强。重要方法是getObject()，返回一个bean，因此我们去看一下getObject方法的实现，实际它的getObject方法的实现在其父类RepositoryFactoryBeanSupport中。

1. @Nonnull

2. public T getObject() {

3. return this.repository.get();

4. }

好像没什么东西，有点懵，那我们先忽略它，我们再一想，JpaRepositoryFactoryBean对象也是一个Bean，那有没有一点和bean实例化过程相关的代码，然后我们找到了这块代码：

1. @Override

2. public void afterPropertiesSet() {

3. 
Assert.state(entityManager != null, "EntityManager must not be null!");


4.  

5. super.afterPropertiesSet();

6. }

而确实JpaRepositoryFactoryBean的父类RepositoryFactoryBeanSupport也实现了InitializingBean接口，它自身也是调用了父类的afterPropertiesSet方法。

1. // 以下代码实现在org.springframework.data.repository.core.support.RepositoryFactoryBeanSupport中

2. public void afterPropertiesSet() {

3. 


4.   this.factory = createRepositoryFactory();

5.  this.factory.setQueryLookupStrategyKey(queryLookupStrategyKey);

6.   this.factory.setNamedQueries(namedQueries);

7.   this.factory.setEvaluationContextProvider(

8.   evaluationContextProvider.orElseGet(() -> QueryMethodEvaluationContextProvider.DEFAULT));

9.  this.factory.setBeanClassLoader(classLoader);

10.  this.factory.setBeanFactory(beanFactory);


11.  

12.  if (publisher != null) {

13.   this.factory.addRepositoryProxyPostProcessor(new EventPublishingRepositoryProxyPostProcessor(publisher));

14. }

15. 


16. repositoryBaseClass.ifPresent(this.factory::setRepositoryBaseClass);


17.  

18.  this.repositoryFactoryCustomizers.forEach(customizer -> customizer.customize(this.factory));


19.  

20.  RepositoryFragments customImplementationFragment = customImplementation //

21.   .map(RepositoryFragments::just) //

22.   .orElseGet(RepositoryFragments::empty);


23.  

24.  RepositoryFragments repositoryFragmentsToUse = this.repositoryFragments //

25.   .orElseGet(RepositoryFragments::empty) //

26.  .append(customImplementationFragment);


27.  

28.  this.repositoryMetadata = this.factory.getRepositoryMetadata(repositoryInterface);


29.  

30. this.repository = Lazy.of(() -> this.factory.getRepository(repositoryInterface, repositoryFragmentsToUse));


31.  

32.  // Make sure the aggregate root type is present in the MappingContext (e.g. for auditing)

33.   this.mappingContext.ifPresent(it -> it.getPersistentEntity(repositoryMetadata.getDomainType()));


34.  

35. if (!lazyInit) {

36. this.repository.get();

37.   }

38. }

逻辑有点多，我们先看到这一行代码：

1. this.repository = Lazy.of(() -> this.factory.getRepository(repositoryInterface, repositoryFragmentsToUse));

先提一句Lazy类继承了java.util.function.Supplier接口。这个this.repository我们是不是在getObject方法有看到，我们还发现它的get方法返回的结果是由this.factory.getRepository()得到的，那这个this.factory又是谁呢，这时我们就要返回来看afterPropertiesSet方法的第一行代码：

1. this.factory = createRepositoryFactory();

直接看createRepositoryFactory方法，它是在JpaRepositoryFactoryBean的直接父类TransactionalRepositoryFactoryBeanSupport中实现的。

1. protected finalRepositoryFactorySupport createRepositoryFactory() {


2.  

3.  RepositoryFactorySupport factory = doCreateRepositoryFactory();


4.  

5.  RepositoryProxyPostProcessor exceptionPostProcessor = this.exceptionPostProcessor;


6.  

7.  if (exceptionPostProcessor != null) {

8.  factory.addRepositoryProxyPostProcessor(exceptionPostProcessor);

9.   }

10. 


11.  RepositoryProxyPostProcessor txPostProcessor = this.txPostProcessor;


12.  

13.  if (txPostProcessor != null) {

14.  factory.addRepositoryProxyPostProcessor(txPostProcessor);

15.   }

16. 


17.  return factory;

18. }

我们直接看关键代码 -- doCreateRepositoryFactory方法，这个是由JpaRepositoryFactoryBean类自己实现的。

1. protected RepositoryFactorySupport doCreateRepositoryFactory() {


2.  

3. Assert.state(entityManager != null, "EntityManager must not be null!");


4.  

5. return createRepositoryFactory(entityManager);

6. }


7.  

8. /**

9.  * Returns a {@link RepositoryFactorySupport}.

10.  */

11. protected RepositoryFactorySupport createRepositoryFactory(EntityManager entityManager) {


12.  

13.  JpaRepositoryFactory jpaRepositoryFactory = new JpaRepositoryFactory(entityManager);

14.  jpaRepositoryFactory.setEntityPathResolver(entityPathResolver);

15.  jpaRepositoryFactory.setEscapeCharacter(escapeCharacter);


16.  

17.  if (queryMethodFactory != null) {

18.  jpaRepositoryFactory.setQueryMethodFactory(queryMethodFactory);

19.  }

20. 


21.  return jpaRepositoryFactory;

22. }

我们直接看到createRepositoryFactory方法，它最后返回是一个JpaRepositoryFactory类型的对象，其他的我们就先不关心了，直接看JpaRepositoryFactory类。我们先来一张类关系图：

我们直奔我们的主题-- getRepository方法，它是在JpaRepositoryFactory的父类RepositoryFactorySupport中实现的。

1. public <T> T getRepository(Class<T> repositoryInterface, RepositoryFragments fragments) {


2.  

3. ...


4.  

5. RepositoryInformation information = getRepositoryInformation(metadata, composition);


6.  

7. ...


8.  

9. Object target = getTargetRepository(information);


10.  

11. ...


12.  

13. ProxyFactory result = new ProxyFactory();

14. result.setTarget(target);

15. result.setInterfaces(repositoryInterface, Repository.class, TransactionalProxy.class);


16.  

17. ...


18.  

19. T repository = (T) result.getProxy(classLoader);


20.  

21. ...

22. 


23. return repository;

24. }

实现代码有点多，这里仅展示我们关注的关键代码，去掉其他多余的代码之后，有没有发现上面的逻辑很熟悉，其实就是构建一个代理类实例的过程，因此也解释了为什么我们在第一次调试看到实际注入的是一个JdkDynamicAopProxy类型的实体。那我们得好好看看代理对象的目标对象是怎么得到的，请看getTargetRepository方法，发现他需要一个RepositoryInformation类型的传参，我继续往上找，看到了getRepositoryInformation方法。

1. private RepositoryInformation getRepositoryInformation(RepositoryMetadata metadata,

2.   RepositoryComposition composition) {


3.  

4.  RepositoryInformationCacheKey cacheKey = new RepositoryInformationCacheKey(metadata, composition);


5.  

6. return repositoryInformationCache.computeIfAbsent(cacheKey, key -> {

7.  

8. Class<?> baseClass = repositoryBaseClass.orElse(getRepositoryBaseClass(metadata));


9.  

10. return new DefaultRepositoryInformation(metadata, baseClass, composition);

11.   });

12. }

其中，可以看到一个getRepositoryBaseClass方法

1. protected Class<?> getRepositoryBaseClass(RepositoryMetadata metadata) {

2. return SimpleJpaRepository.class;

3. }

好了，什么也不用说了，它直接给我们返回了SimpleJpaRepository的Class对象。其他的逻辑我们也不看了，虽然还有一些包装和判断的过程，但是我们今天的目的已经达到了，第二个疑惑也算比较好的解答了。最后顺便提一句，如果你的项目是手动使用了@EnableJpaRepositories注解，可能你的调试过程开局会有点不一样，但是后续的逻辑是相同的，自己可以去试试。代码如下：

1. @EnableJpaRepositories(basePackages = "ai.advance.jpademo.repository")

2. @SpringBootApplication

3. public class JpaDemoApplication {

4. 


5. public static void main(String[] args) {

6. SpringApplication.run(JpaDemoApplication.class, args);

7. }

8.  

9. }

3.3自定义查询

我们还有一个疑问，为什么我们自己定义的那些不属于SimpleJpaRepository类的方法也能被调用，并且被正确生成SQL？我们又要回到上节分析的getRepository方法,同样的我们去掉不需要关心的代码。

1. public <T> T getRepository(Class<T> repositoryInterface, RepositoryFragments fragments) {


2.  

3. ...


4.  

5. ProxyFactory result = new ProxyFactory();


6.  

7. ...


8.  

9. Optional<QueryLookupStrategy> queryLookupStrategy = getQueryLookupStrategy(queryLookupStrategyKey,

10. evaluationContextProvider);

11. result.addAdvice(new QueryExecutorMethodInterceptor(information, projectionFactory, queryLookupStrategy,

12. namedQueries, queryPostProcessors, methodInvocationListeners));


13.  

14. result.addAdvice(

15. new ImplementationMethodExecutionInterceptor(information, compositionToUse, methodInvocationListeners));

16.  

17. T repository = (T) result.getProxy(classLoader);


18.  

19. ...


20.  

21. return repository;

22. }

从上面的源码我们可以看到ProxyFactory对象在最后有两次addAdvice方法的调用，目的是为了增加QueryExecutorMethodInterceptor

和ImplementationMethodExecutionInterceptor两个拦截器，它们都实现了MethodInterceptor接口，其中ImplementationMethodExecutionInterceptor为RepositoryFactorySupport的静态内部类。

3.3.1QueryExecutorMethodInterceptor

QueryExecutorMethodInterceptor这个拦截器是用来拦截处理我们在repository接口中自定义的方法的。在QueryExecutorMethodInterceptor的成员变量中有一个定义为Map<Method, RepositoryQuery>类型的queries变量，这个变量主要保存了自定义方法对象与一个RepositoryQuery对象的映射关系。

RepositoryQuery的直接抽象子类是AbstractJpaQuery，可以看到，一个RepositoryQuery实例持有一个JpaQueryMethod实例，JpaQueryMethod又持有一个Method实例，所以RepositoryQuery实例的用途很明显，一个RepositoryQuery代表了Repository接口中的一个方法，根据方法头上注解不同的形态，将每个Repository接口中的方法分别映射成相对应的RepositoryQuery实例。我们通过类关系图来熟悉一下RepositoryQuery具体的实现类有哪些。

下面我们看看JPA在哪些情况下创建对应的那个RepositoryQuery对象

1.SimpleJpaQuery

2.NativeJpaQuery

3.PartTreeJpaQuery

4.NamedQuery

5.StoredProcedureJpaQuery

所以QueryExecutorMethodInterceptor最终的目的就是根据当前需要调用的自定义的Repository的方法找到对应的RepositoryQuery对象，并构建调用信息并使用invoke方法触发调用，主要逻辑在QueryExecutorMethodInterceptor类的doInvoke方法中。

1. private Object doInvoke(MethodInvocation invocation) throws Throwable {


2.  

3. Method method = invocation.getMethod();


4.  

5. if (hasQueryFor(method)) {


6.  

7. RepositoryMethodInvoker invocationMetadata = invocationMetadataCache.get(method);


8.  

9. if (invocationMetadata == null) { invocationMetadata = RepositoryMethodInvoker.forRepositoryQuery(method, queries.get(method));

10. invocationMetadataCache.put(method,

11. invocationMetadata);

12. }


13.  

14. return invocationMetadata.invoke(repositoryInformation.getRepositoryInterface(), invocationMulticaster,

15. invocation.getArguments());

16. }

17. 


18. return invocation.proceed();

19. }

其实最终调用的是RepositoryMethodInvoker类中的doInvoke方法，我们打上断点来看一下

1. public Object invoke(@SuppressWarnings("null") MethodInvocation invocation) throws Throwable {

2.  
3. Method method = invocation.getMethod();
4. Object[] arguments = invocation.getArguments();

5.  
6. try {
7. return composition.invoke(invocationMulticaster, method, arguments);
8. } catch (Exception e) {
9. org.springframework.data.repository.util.ClassUtils.unwrapReflectionException(e);
10. }
11. 

12. throw new IllegalStateException("Should not occur!");
13. }

从上面信息可以看出来ImplementationMethodExecutionInterceptor类的invoke方法调用的是RepositoryComposition类的invoke方法，如果继续深入，其实最终也是调用的RepositoryMethodInvoker类中的doInvoke方法

至此，我们开头的几大疑惑基本都得到了解释。

四、总结