Java Springboot自动装配原理详解

目录
  • Debug路线图
  • 让我们从run说起
    • 归属
    • 小结
  • run
  • 再说说注解
  • 总结

Debug路线图

说多都是泪,大家看图。

让我们从run说起

用了这么多年的的Springboot,这个 run() 方法到底做了些什么事呢?

@SpringBootApplication
public class SpringbootDemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(SpringbootDemoApplication.class, args);
    }
}

归属

run() 方法归属于 SpringApplication.class 对象,所以在调用run() 方法前,需要先实例化 SpringApplication.class 对象:

	public static ConfigurableApplicationContext run(Class<?>[] primarySources, String[] args) {
		return new SpringApplication(primarySources).run(args);
	}

SpringApplication.class 对象实例化时,都做了些什么事呢?

这里主要看需要注意两个方法:①getSpringFactoriesInstances() 和 ②deduceMainApplicationClass()

/**
 * 实例化时,实际调用的构造方法
 */
public SpringApplication(ResourceLoader resourceLoader, Class<?>... primarySources) {
		this.resourceLoader = resourceLoader;
		Assert.notNull(primarySources, "PrimarySources must not be null");
		this.primarySources = new LinkedHashSet<>(Arrays.asList(primarySources));
		// 这里将spring.
		this.webApplicationType = WebApplicationType.deduceFromClasspath();
		this.bootstrapRegistryInitializers = getBootstrapRegistryInitializersFromSpringFactories();
		// 设置初始化器
		setInitializers((Collection) getSpringFactoriesInstances(ApplicationContextInitializer.class));
		// 设置监听器
		setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class));
		this.mainApplicationClass = deduceMainApplicationClass();
	}

getSpringFactoriesInstances()方法主要加载整个应用程序中的 spring.factories 文件,将文件的内容放到缓存对象中,方便后续获取使用。

private static Map<String, List<String>> loadSpringFactories(ClassLoader classLoader) {
		// 初次加载,cache中获取不到数据,所以为null
		Map<String, List<String>> result = cache.get(classLoader);
		if (result != null) {
			return result;
		}
		result = new HashMap<>();
		try {
			// FACTORIES_RESOURCE_LOCATION = "META-INF/spring.factories",这个配置类眼熟吧
			// 加载配置类
			Enumeration<URL> urls = classLoader.getResources(FACTORIES_RESOURCE_LOCATION);
			while (urls.hasMoreElements()) {
				URL url = urls.nextElement();
				UrlResource resource = new UrlResource(url);
				// 这里加载资源
				Properties properties = PropertiesLoaderUtils.loadProperties(resource);
				for (Map.Entry<?, ?> entry : properties.entrySet()) {
					String factoryTypeName = ((String) entry.getKey()).trim();
					String[] factoryImplementationNames =
							StringUtils.commaDelimitedListToStringArray((String) entry.getValue());
					for (String factoryImplementationName : factoryImplementationNames) {
						result.computeIfAbsent(factoryTypeName, key -> new ArrayList<>())
								.add(factoryImplementationName.trim());
					}
				}
			}
			// Replace all lists with unmodifiable lists containing unique elements
			result.replaceAll((factoryType, implementations) -> implementations.stream().distinct()
					.collect(Collectors.collectingAndThen(Collectors.toList(), Collections::unmodifiableList)));
			// 这里将获取到资源放入cache中
			cache.put(classLoader, result);
		}
		catch (IOException ex) {
			throw new IllegalArgumentException("Unable to load factories from location [" +
					FACTORIES_RESOURCE_LOCATION + "]", ex);
		}
		return result;
	}

deduceMainApplicationClass() 方法返回了启动类的类信息:

小结

实例化SpringApplication.class 对象完成了两件事:

1.加载整个应用程序中的 spring.factories 文件,将文件的内容放到缓存对象中,方便后续获取使用。

2.返回了启动类的类信息。

run

有了SpringApplication.class 对象实例对象,接下来就可以调用run() 方法。

在run() 方法中,我们主要关注两个方法prepareContext() 和 refreshContext()

public ConfigurableApplicationContext run(String... args) {
// 省略部分代码
	try {
		prepareContext(bootstrapContext, context, environment, listeners, applicationArguments, printedBanner);
		refreshContext(context);
	}
// 省略部分代码

prepareContext()方法准备上下文环境,通过调用load()方法加载启动类,为获取启动类上的注解做准备;

private void load(Class<?> source) {
		if (isGroovyPresent() && GroovyBeanDefinitionSource.class.isAssignableFrom(source)) {
			// Any GroovyLoaders added in beans{} DSL can contribute beans here
			GroovyBeanDefinitionSource loader = BeanUtils.instantiateClass(source, GroovyBeanDefinitionSource.class);
			((GroovyBeanDefinitionReader) this.groovyReader).beans(loader.getBeans());
		}
		// 这里会判断启动类不是一个groovy闭包也不是一个匿名类
		if (isEligible(source)) {
			// 注册读取启动类的注解信息
			// 注意,这里将启动类型注册为AnnotatedBeanDefinition类型,后面parse()解析时会用到。
			this.annotatedReader.register(source);
		}
	}

refreshContext() 方法最终调用了AbstractApplicationContext.class 类的 refresh(),这里相信看过spring源码的小伙伴都很熟悉 refresh() 这个方法。

自动装配操作的主战场主要是在 ①invokeBeanFactoryPostProcessors() 方法,①调用了②invokeBeanDefinitionRegistryPostProcessors() 方法,②调用了ConfigurationClassPostProcessor.class 的③postProcessBeanDefinitionRegistry()方法,③调用了 ④processConfigBeanDefinitions() 方法;

④ processConfigBeanDefinitions() 方法中:

public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
		List<BeanDefinitionHolder> configCandidates = new ArrayList<>();
		String[] candidateNames = registry.getBeanDefinitionNames();
		// 这里会循环匹配到启动类,并且添加到上面的configCandidates集合中。
		for (String beanName : candidateNames) {
			BeanDefinition beanDef = registry.getBeanDefinition(beanName);
			if (beanDef.getAttribute(ConfigurationClassUtils.CONFIGURATION_CLASS_ATTRIBUTE) != null) {
				if (logger.isDebugEnabled()) {
					logger.debug("Bean definition has already been processed as a configuration class: " + beanDef);
				}
			}
			else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
				configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
			}
		}

		// ...

		// 解析每一个标注了@Configuration注解的类,启动类上的@SpringBootApplication就包含了@Configuration注解
		ConfigurationClassParser parser = new ConfigurationClassParser(
				this.metadataReaderFactory, this.problemReporter, this.environment,
				this.resourceLoader, this.componentScanBeanNameGenerator, registry);
				Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates);
		Set<ConfigurationClass> alreadyParsed = new HashSet<>(configCandidates.size());
		do {
			StartupStep processConfig = this.applicationStartup.start("spring.context.config-classes.parse");
			// 开始解析
			parser.parse(candidates);
			parser.validate();
	}
		// ============ 分割线 =================
/**
 * 为了方便阅读,这里将parse()方法接入
 */
public void parse(Set<BeanDefinitionHolder> configCandidates) {
		for (BeanDefinitionHolder holder : configCandidates) {
			BeanDefinition bd = holder.getBeanDefinition();
			try {
				// 在前面prepareContext()方法中的load()方法中已经说过,所以这会进入这个判断解析
				if (bd instanceof AnnotatedBeanDefinition) {
					parse(((AnnotatedBeanDefinition) bd).getMetadata(), holder.getBeanName());
				}
		// ...
		}
		// 注意!!这里,parse()解析完成后,会回到这里执行process()方法;
		this.deferredImportSelectorHandler.process();
	}

进入判断后parse()方法会接着调用 ①processConfigurationClass()方法,①调用②doProcessConfigurationClass()方法;

doProcessConfigurationClass()中又开始对注解进行进一步的解析,包括@PropertySource、@ComponentScan、@Import(咱们看这个)、@ImportResource、@Bean,解析之前,会通过getImports()方法调用collectImports()方法,统计出被@Import标注的类型信息;

	protected final SourceClass doProcessConfigurationClass(
			ConfigurationClass configClass, SourceClass sourceClass, Predicate<String> filter)
			throws IOException {
		// ...
		// Process any @Import annotations
		processImports(configClass, sourceClass, getImports(sourceClass), filter, true);
		// ...
// ============ 分割线 =================
private Set<SourceClass> getImports(SourceClass sourceClass) throws IOException {
		Set<SourceClass> imports = new LinkedHashSet<>();
		Set<SourceClass> visited = new LinkedHashSet<>();
		collectImports(sourceClass, imports, visited);
		return imports;
	}
private void collectImports(SourceClass sourceClass, Set<SourceClass> imports, Set<SourceClass> visited)
			throws IOException {

		if (visited.add(sourceClass)) {
			for (SourceClass annotation : sourceClass.getAnnotations()) {
				String annName = annotation.getMetadata().getClassName();
				if (!annName.equals(Import.class.getName())) {
					// 注意看这里,自调用递归查询
					collectImports(annotation, imports, visited);
				}
			}
			imports.addAll(sourceClass.getAnnotationAttributes(Import.class.getName(), "value"));
		}
	}
}

getImports() 方法查询结果展示:

parse()方法解析完成 @Import 注解后(这里忘记的小伙伴,可看看上面的parse()方法,我有代码注释),接着开始调用①process()方法,①中调用②processGroupImports()方法,②中接着调用 ③grouping.getImports()方法,③调用DeferredImportSelector.Group 接口的 ④process()方法,这里我们看它的实现类 AutoConfigurationImportSelector.class 实现的 ④process()方法(这里需要留意一下,一会还会回来用到),④调用了 ⑤getAutoConfigurationEntry(),⑤中调用了⑥getCandidateConfigurations() 方法;

重点来了:经过上面的一系列方法调用,终于来到这个方法,相信大家在许多博客里都又看到过 ⑥getCandidateConfigurations() 这个方法,但又没有说清楚具体是怎么调用到这个方法的,只是说了这个类会得到待配置的class的类名集合等等;

在⑥这个方法中,显示通过 ⑦getSpringFactoriesLoaderFactoryClass() 这个方法返回了一个EnableAutoConfiguration.class 注解对象,然后又通过调用 ⑧loadFactoryNames(),⑧又调用了 ⑨loadSpringFactories();

⑧⑨方法看着是不是比较眼熟? 是的,我们在初始化SpringApplication对象时,曾调用过这两个方法,在调用⑨时,将 spring.factories 文件的内容放到cache缓存对象中。

@Override
protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
		// getSpringFactoriesLoaderFactoryClass()这个方法返回了一个EnableAutoConfiguration.class注解对象
		List<String> configurations = SpringFactoriesLoader.loadFactoryNames(getSpringFactoriesLoaderFactoryClass(),
				getBeanClassLoader());
		Assert.notEmpty(configurations, "No auto configuration classes found in META-INF/spring.factories. If you "
				+ "are using a custom packaging, make sure that file is correct.");
		return configurations;
}

protected Class<?> getSpringFactoriesLoaderFactoryClass() {
		return EnableAutoConfiguration.class;
}
// ===========================分割线===========================
private static Map<String, List<String>> loadSpringFactories(ClassLoader classLoader) {
		Map<String, List<String>> result = cache.get(classLoader);
		if (result != null) {
			return result;
		}
	// ...

此时的cache对象中存在EnableAutoConfiguration对象,size=131个:

这131个就是 spring.factories 文件中的自动装配配置项:

当然,这里面有许多我们没有用到类信息也被装配了进来,这里不要着急接着往下看,装配完成后回到了⑤getAutoConfigurationEntry()方法中,且返回了一个List< String>的一个配置类信息集合,接着又做了些什么事?

从上图可以看出,131个配置信息,经过过滤移除后,最终变成13个需要使用的,拿到最终配置信息,(愣着干嘛,赶紧撒花呀!),到这里自动装配过程基本上就结束了。

这里的结束是指自动装配过程结束,也就是我们 refresh()中的invokeBeanFactoryPostProcessors() 方法执行结束,当然这个方法还做很多别的事,但是本文只关注自动装配相关,完成此方法后并不表示类就已经实例化完成,这里只是将类信息装配到了spring容器中,后续会有别的方法完成类的实例化。(实例化看它:finishBeanFactoryInitialization())

再说说注解

@SpringBootApplication 是的没错,这个注解大家都熟悉,springboot 项目启动类上都有:

@SpringBootApplication 中包含了两个注解:

  • @EnableAutoConfiguration(重点):启用 SpringBoot 的自动配置机制;
  • @ComponentScan: 扫描被@Component (@Service,@Controller)注解的 bean,注解默认会扫描该类所在的包下所有的类;
  • @SpringBootConfiguration:允许在上下文中注册额外的 bean 或导入其他配置类;

三个注解中,自动装配的核心 @EnableAutoConfiguration 就是这个注解:

@EnableAutoConfiguration 注解通过 Spring 提供的 @Import 注解导入了 AutoConfigurationImportSelector.class类(@Import 注解可以导入配置类或者 Bean 到当前类中),这个类的作用在上也说过(获取spring.factories文件中待配置的class的类名集合)。

总结

本篇文章就到这里了,希望能够给你带来帮助,也希望您能够多多关注我们的更多内容!

(0)

相关推荐

  • SpringBoot自动装配Condition的实现方式

    目录 1. 简介 2. 定义 2.1 @Conditional 2.2 Condition 3. 使用说明 3.1 创建项目 3.2 测试 3.3 小结 4. 改进 4.1 创建注解 4.2 修改UserCondition 5. Spring内置条件注解 1. 简介 @Conditional注解在Spring4.0中引入,其主要作用就是判断条件是否满足,从而决定是否初始化并向容器注册Bean. 2. 定义 2.1 @Conditional @Conditional注解定义如下:其内部只有一个参数

  • springboot自动装配的源码与流程图

    前言 在使用SpringBoot开发项目中,遇到一些 XXX-XXX-starter,例如mybatis-plus-boot-starter,这些包总是能够自动进行配置, 减少了开发人员配置一些项目配置的时间,让开发者拥有更多的时间用于开发的任务上面.下面从源码开始. 正文 SpringBoot版本:2.5.3 从@SpringBootApplication进入@EnableAutoConfiguration 然后进入AutoConfigurationImportSelector @Target

  • SpringBoot自动装配原理详解

    首先对于一个SpringBoot工程来说,最明显的标志的就是 @SpringBootApplication它标记了这是一个SpringBoot工程,所以今天的 SpringBoot自动装配原理也就是从它开始说起. 自动装配流程 首先我们来看下@SpringBootApplication 这个注解的背后又有什么玄机呢,我们按下 ctrl + 鼠标左键,轻轻的点一下,此时见证奇迹的时刻.. 我们看到如下优雅的代码: 这其中有两个比较容易引起我们注意的地方,一个是@SpringBootConfigur

  • springboot自动装配原理初识

    运行原理 为了研究,我们正常从父项目的pom.xml开始进行研究. pom.xml 父依赖 spring-boot-starter-parent主要用来管理项目的资源过滤和插件 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.2.5.RELEASE<

  • 浅谈springboot自动装配原理

    一.SpringBootApplication @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @SpringBootConfiguration @EnableAutoConfiguration @ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFi

  • SpringBoot自动装配原理小结

    约定优于配置(Convention Over Configuration)是一种软件设计范式,目的在于减少配置的数量或者降低理解难度,从而提升开发效率. 先总结一下结论: springboot通过spring.factories能把main方法所在类路径以外的bean自动加载,其目的就是为了帮助自动配置bean,减轻配置量 springboot autoconfig的一些实验 一个springboot工程,springbootautoconfig.test.config这个包和启动类的包不再同一

  • Java SpringBoot自动装配原理详解及源码注释

    目录 一.pom.xml文件 1.父依赖 2.启动器: 二.主程序: 剖析源码注解: 三.结论: 一.pom.xml文件 1.父依赖 主要是依赖一个父项目,管理项目的资源过滤以及插件! 资源过滤已经配置好了,无需再自己配置 在pom.xml中有个父依赖:spring-boot-dependencies是SpringBoot的版本控制中心! 因为有这些版本仓库,我们在写或者引入一些springboot依赖的时候,不需要指定版本! 2.启动器: 启动器也就是Springboot的启动场景; 比如sp

  • Java Springboot自动装配原理详解

    目录 Debug路线图 让我们从run说起 归属 小结 run 再说说注解 总结 Debug路线图 说多都是泪,大家看图. 让我们从run说起 用了这么多年的的Springboot,这个 run() 方法到底做了些什么事呢? @SpringBootApplication public class SpringbootDemoApplication { public static void main(String[] args) { SpringApplication.run(Springboot

  • SpringBoot自动配置原理详解

    目录 阅读收获 一.SpringBoot是什么 二.SpringBoot的特点 三.启动类 3.1 @SpringBootApplication 四.@EnableAutoConfiguration 4.1 @AutoConfigurationPackage 4.2  @Import({AutoConfigurationImportSelector.class}) 五.流程总结图 六.常用的Conditional注解 七.@Import支持导入的三种方式 阅读收获 理解SpringBoot自动配

  • 深入了解Java SpringBoot自动装配原理

    目录 自动装配原理 SpringBootApplication EnableAutoConfiguration AutoConfigurationImportSelector 总结 在使用springboot时,很多配置我们都没有做,都是springboot在帮我们完成,这很大一部分归功于springboot自动装配,那springboot的自动装配的原理是怎么实现的呢? 自动装配原理 springboot 版本:2.4.3 SpringBootApplication springboot启动类

  • Java SpringBoot自动配置原理详情

    目录 SpringBoot的底层注解 配置绑定 自动配置原理入门 SpringBoot的底层注解 首先了解一些SpringBoot的底层注解,是如何完成相关的功能的 @Configuration 告诉SpringBoot被标注的类是一个配置类,以前Spring xxx.xml能配置的内容,它都可以做,spring中的Bean组件默认是单实例的 #############################Configuration使用示例###############################

  • Java SpringBoot Validation用法案例详解

    目录 constraints分类 对象集成constraints示例 SpringBoot集成自动验证 集成maven依赖 验证RequestBody.Form对象参数 验证简单参数 验证指定分组 全局controller验证异常处理 自定义constraints @DateFormat @PhoneNo 使用自定义constraint注解 问题 提到输入参数的基本验证(非空.长度.大小.格式-),在以前我们还是通过手写代码,各种if.else.StringUtils.isEmpty.Colle

  • 四种引用类型在JAVA Springboot中的使用详解

    目录 概念介绍 01.  强引用 02.  软引用 03.  弱引用 04.  虚引用 对象可达性 Springboot源码中的使用 总结 概念介绍 不同的引用类型,主要体现的是对象不同的可达性(reachable)状态和对垃圾收集的影响. 01.  强引用 这个就是我们创建的普通对象了~ 当该对象被显示地赋值为 null 时,或者没有被其他存活的对象继续引用时,它就会成为垃圾收集器的目标,等待被收回 02.  软引用 软引用( SoftReference ) , 当内存不足 时会被回收 比如

随机推荐