【SpringBoot2 从0开始】自动配置原理入门(源码分析)

简介: 【SpringBoot2 从0开始】自动配置原理入门(源码分析)

之前为什么会去了解一些底层注解,其实就是为了后续更好的了解 springboot 底层的一些原理,比如自动配置原理。


一、@SpringBootApplication


从 MainApplication 中的@SpringBootApplication开始。


1268169-20210903122749879-1589215757.png


进入@SpringBootApplication,可以看到这是一个合成注解(红框中是要关注的)。


1268169-20210903122535825-1685129639.png


1. @SpringBootConfiguration


这个注解干嘛的?


直接点进去,发现有一个@Configuration注解,那这不就是个配置类嘛。


1268169-20210903122324959-903329229.png


进而也说明了,MainApplication 也是一个配置类。


2. @ComponentScan


这个已经很熟悉了,可以指定扫描哪些 Spring 注解。


只不过这里,加了一些其他的过滤条件,暂时不关注。


3. @EnableAutoConfiguration


这个是最重要的注解了,听名字就不一般,开启自动配置。


点进去,发现也是一个合成注解(红框需要关注)。


1268169-20210903123347624-108822373.png


(1)@AutoConfigurationPackage


听名字像是自动配置包?依旧点进去。


1268169-20210903123611528-100390823.png


可以看到原来是导入了一个叫Registrar的组件,继续点进 Registrar


1268169-20210903123846653-1649411999.png


这里是利用Registrar()给容器中导入一系列组件,也就是批量注册组件

在这里打个断点,debug 启动一下。


1268169-20210903124145571-1804273479.png


registerBeanDefinitions()方法中有个传参:


  • metadata,是注解的元信息,可以看到这个注解是被标注在com.pingguo.boot.MainApplication

而在registerBeanDefinitions()方法体内,new 了一个AutoConfigurationPackages.PackageImports(),里面传入的是元注解,通过getPackageNames()获取到包名。


AutoConfigurationPackages.register(
    registry, (String[])(new AutoConfigurationPackages.PackageImports(metadata)).getPackageNames().toArray(new String[0])
);


在 idea 中可以单独执行下片段代码(new AutoConfigurationPackages.PackageImports(metadata)).getPackageNames()


1268169-20210906221530060-1242938433.png


选中右击,再点击 Evaluate。


1268169-20210906221631927-950115851.png


得到的结果就是com.pingguo.boot。为什么是这个?因为注解标注在MainApplication类,而这个类就属于com.pingguo.boot


拿到包名之后,封装到数组里,也就是上述代码片段中的toArray(new String[0]),最后注册进去。


所以,这里的Registrar()就是把指定的包下的所有组件批量注册到容器中。


(2)@Import(AutoConfigurationImportSelector.class)


上面指定好默认包规则之后,就需要去导入需要的包了,利用的是AutoConfigurationImportSelector,继续点进去看。


1268169-20210906222914218-1025869732.png


这里有个selectImports方法,这个方法决定了要具体导入哪些,返回的是一个数组。


方法体内,又是调用了getAutoConfigurationEntry()方法来获取配置入口,进而再通过getConfigurations()方法获取具体配置,最终转成数组返回。


显然getAutoConfigurationEntry()是个重点。


往下翻一点,就是getAutoConfigurationEntry()的实现,在这里打个断点(把上面的断点取消掉)。


1268169-20210906223630103-748611217.png


debug重新运行一下,往下走到getCandidateConfigurations()


1268169-20210906223724339-570680576.png


这里是获取所有候选配置,目前可以看到这里是共有 127 个。


1268169-20210906224246634-1571417369.png


为什么是这 127 个?其实是在配置文件里写死了,在 springboot 启动时候,给容器加载的所有场景的配置类。


定义的位置是在这:\spring-boot-autoconfigure\2.3.4.RELEASE\spring-boot-autoconfigure-2.3.4.RELEASE.jar!\META-INF\spring.factories


1268169-20210906225348466-324323042.png


虽然这些一股脑的在启动时候会去加载到容器,但是最终会按需开启配置。


1268169-20210906231028892-2012128602.png


比如点开aop,看到@ConditionalOnClass({Advice.class})这个条件,是当存在Advice类时候才导入组件,但实际上这里并没有Advice


这就是基于 springboot 的按条件装配@Conditional,根据规则最终实现按需装配。


二、自动配置示例


分别用最终未生效、和生效的自动配置来加深理解。


1. 未生效的自动配置


比如 cache。


1268169-20210906232927216-1769376670.png


可以看到CacheAutoConfiguration上是加了几个条件装配的。


1268169-20210906233050325-580596180.png


(1)@ConditionalOnClass({CacheManager.class})


在 idea 中使用ctrl+N搜索一下CacheManager,发现是存在的,那么这个条件满足。


1268169-20210906233241896-2114048875.png


(2)@ConditionalOnBean({CacheAspectSupport.class})


这个条件是要求容器中存在CacheAspectSupport这个组件才可以。


现在来判断一下是否存在这个组件,在 main 方法里增加测试代码:


... ...
      String[] beanNamesForType = run.getBeanNamesForType(CacheAspectSupport.class);
      System.out.println("==CacheAspectSupport类型组件的数量==" + beanNamesForType.length);
... ...


运行查看输出。


1268169-20210906233732489-1943571849.png


发现数量等于 0,也就是不存在该类型的组件。


也就是说@ConditionalOnBean({CacheAspectSupport.class})这个条件不满足,所以整个类CacheAutoConfiguration里的配置都不生效。


2. 生效的自动配置


之前写过 web 的demo,那么 web 相关的配置自然是生效的,找到它。


1268169-20210906234152752-302434392.png


这里有不少后缀是**AutoConfiguration的配置,直接来看DispatcherServletAutoConfiguration


1268169-20210907191157696-271631285.png


  • @Configuration(proxyBeanMethods = false):表示是一个配置类。
  • @ConditionalOnWebApplication(type = Type.SERVLET):条件是否为一个 web 应用,而且是原生 SERVLET 类型的(因为springboot2还有webflux),当前满足条件。
  • @ConditionalOnClass({DispatcherServlet.class}):条件是否导入了DispatcherServlet类,这里也是有的。


1268169-20210907191836201-977612714.png


还有 2 个注解直接没见过,这里不用太多关注,了解一下:

  • @AutoConfigureOrder:这个配置类的配置优先级顺序。
  • @AutoConfigureAfter:表示在xx之后才配置这个类,这里就是在配置完ServletWebServerFactoryAutoConfiguration.class后,再配置当前的类。

所以,类上的几个条件都是满足的,就可以进一步到类中了,继续往下找:


1268169-20210907222456078-325383877.png


看到DispatcherServletConfiguration类上也有条件:


  • @Conditional({DispatcherServletAutoConfiguration.DefaultDispatcherServletCondition.class}):


别看这么长,其实就是上面的一个类


  • @ConditionalOnClass({ServletRegistration.class}): 这个也存在。


1268169-20210907222825272-1143884718.png


  • @EnableConfigurationProperties({WebMvcProperties.class})

这个很熟悉了,使用前面刚学习完不久,它并不是条件装配,而是用来绑定外部配置文件的,点进去。


1268169-20210907223105305-1923540050.png


可以看到,会与配置文件中前缀是spring.mvc的所有属性进行绑定。


另外,还可以自动把组件注册到容器中去。


这里可以试一下,在 main 方法里增加输出:


String[] beanNamesForType1 = run.getBeanNamesForType(WebMvcProperties.class);
    System.out.println("==WebMvcProperties类型组件的数量==" + beanNamesForType1.length);


运行一下,果然是有一个:


1268169-20210907223506463-158233528.png


到此,说明DispatcherServletConfiguration这个配置类也是生效的。


继续往下就看到方法dispatcherServlet(),而且是加了@Bean注解,就是给容器中注册DispatcherServlet类型的组件。


1268169-20210907223753022-1078433554.png


这里的经过是:


  • new 一个DispatcherServlet()对象dispatcherServlet
  • 接着对dispatcherServlet一通 set 设置。
  • 最后返回这个对象dispatcherServlet


在之前学习 springMVC 时候,还要手动去设置关于DispatcherServlet的一堆东西。而在 springboot 里已经在底层设置好了,并且注册到容器中去了,所以我们能直接使用。


三、小结


随着进一步跟着源码来理解自动配置的原理,使得自己更深的体会到 springboot 的优点。


那么多东西不需要我们手动去配置了,并不是说用不上,而是在底层springboot已经帮我们完成好了配置。


当然,目前的重点还是学会使用 springboot,但是带着之前对 springboot 的疑问来学习,还是更有收获的。

相关文章
|
11天前
|
Java 数据库连接 Maven
最新版 | 深入剖析SpringBoot3源码——分析自动装配原理(面试常考)
自动装配是现在面试中常考的一道面试题。本文基于最新的 SpringBoot 3.3.3 版本的源码来分析自动装配的原理,并在文未说明了SpringBoot2和SpringBoot3的自动装配源码中区别,以及面试回答的拿分核心话术。
最新版 | 深入剖析SpringBoot3源码——分析自动装配原理(面试常考)
|
11天前
|
Java Maven Spring
SpringBoot配置跨模块扫描问题解决方案
在分布式项目中,使用Maven进行多模块开发时,某些模块(如xxx-common)没有启动类。如何将这些模块中的类注册为Spring管理的Bean对象?本文通过案例分析,介绍了两种解决方案:常规方案是通过`@SpringBootApplication(scanBasePackages)`指定扫描路径;推荐方案是保持各模块包结构一致(如com.xxx),利用SpringBoot默认扫描规则自动识别其他模块中的组件,简化配置。
SpringBoot配置跨模块扫描问题解决方案
|
18天前
|
NoSQL Java Redis
Spring Boot 自动配置机制:从原理到自定义
Spring Boot 的自动配置机制通过 `spring.factories` 文件和 `@EnableAutoConfiguration` 注解,根据类路径中的依赖和条件注解自动配置所需的 Bean,大大简化了开发过程。本文深入探讨了自动配置的原理、条件化配置、自定义自动配置以及实际应用案例,帮助开发者更好地理解和利用这一强大特性。
68 14
|
2月前
|
缓存 IDE Java
SpringBoot入门(7)- 配置热部署devtools工具
SpringBoot入门(7)- 配置热部署devtools工具
56 1
SpringBoot入门(7)- 配置热部署devtools工具
|
2月前
|
Java 容器
springboot自动配置原理
启动类@SpringbootApplication注解下,有三个关键注解 (1)@springbootConfiguration:表示启动类是一个自动配置类 (2)@CompontScan:扫描启动类所在包外的组件到容器中 (3)@EnableConfigutarion:最关键的一个注解,他拥有两个子注解,其中@AutoConfigurationpackageu会将启动类所在包下的所有组件到容器中,@Import会导入一个自动配置文件选择器,他会去加载META_INF目录下的spring.factories文件,这个文件中存放很大自动配置类的全类名,这些类会根据元注解的装配条件生效,生效
|
2月前
|
存储 前端开发 JavaScript
springboot中路径默认配置与重定向/转发所存在的域对象
Spring Boot 提供了简便的路径默认配置和强大的重定向/转发机制,通过合理使用这些功能,可以实现灵活的请求处理和数据传递。理解并掌握不同域对象的生命周期和使用场景,是构建高效、健壮 Web 应用的关键。通过上述详细介绍和示例,相信读者能够更好地应用这些知识,优化自己的 Spring Boot 应用。
40 3
|
Java Maven 容器
SpringBoot 核心原理分析
SpringBoot 核心原理分析
197 0
SpringBoot 核心原理分析
|
XML Java 数据格式
SpringBoot原理分析
SpringBoot原理分析
SpringBoot原理分析
|
3月前
|
JavaScript 安全 Java
如何使用 Spring Boot 和 Ant Design Pro Vue 实现动态路由和菜单功能,快速搭建前后端分离的应用框架
本文介绍了如何使用 Spring Boot 和 Ant Design Pro Vue 实现动态路由和菜单功能,快速搭建前后端分离的应用框架。首先,确保开发环境已安装必要的工具,然后创建并配置 Spring Boot 项目,包括添加依赖和配置 Spring Security。接着,创建后端 API 和前端项目,配置动态路由和菜单。最后,运行项目并分享实践心得,包括版本兼容性、安全性、性能调优等方面。
199 1
|
2月前
|
JavaScript 安全 Java
如何使用 Spring Boot 和 Ant Design Pro Vue 构建一个具有动态路由和菜单功能的前后端分离应用。
本文介绍了如何使用 Spring Boot 和 Ant Design Pro Vue 构建一个具有动态路由和菜单功能的前后端分离应用。首先,创建并配置 Spring Boot 项目,实现后端 API;然后,使用 Ant Design Pro Vue 创建前端项目,配置动态路由和菜单。通过具体案例,展示了如何快速搭建高效、易维护的项目框架。
131 62