前言
我置信,只有你用过 Spring Boot,就会对这样一个景象十分的好奇:
引入一个组件依赖,加个配置,这个组件就失效了。
举个例子来说,比方咱们罕用的 Redis, 在 Spring Boot 中的应用形式是这样的:
1. 引入依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
2. 编写配置
spring:
redis:
database: 0
timeout: 5000ms
host: 127.0.0.1
port: 6379
password: 123456
好了,接下来只须要应用时注入 RedisTemplate 就能应用了,像这样:
@Autowired
private RedisTemplate redisTemplate;
这期间,咱们做了什么嘛?咱们什么也没有做,那么,这个 RedisTemplate
对象是怎么注入到 Spring 容器中的呢?
接下来,就让咱们带着这样的疑难逐渐分析其中的原理,这个原理就叫做主动拆卸。
SPI
先不焦急,在这之前,咱们先来理解理解上古大法:SPI 机制。
SPI,全称为 Service Provider Interface(服务提供者接口),是一种服务发现机制。它通过在 classpath 门路下的 META-INF/services 文件夹查找文件,主动加载文件中所定义的类。
栗子
建一个工程,构造如下
provider 为服务提供方,能够了解为咱们的框架
zoo 为应用方,因为我的服务提供接口叫Animal
,所以所有实现都是动物~
pom.xml 外面啥都没有
1. 定义一个接口
在 provider 模块中定义接口Animal
package cn.zijiancode.spi.provider;
/**
* 服务提供者 动物
*/
public interface Animal {
// 叫
void call();}
2. 应用该接口
在 zoo 模块中引入 provider
<dependency>
<groupId>cn.zijiancode</groupId>
<artifactId>provider</artifactId>
<version>1.0.0</version>
</dependency>
写一个小猫咪实现 Animal
接口
public class Cat implements Animal {
@Override
public void call() {System.out.println("喵喵喵~~");
}
}
写一个狗子也实现 Animal
接口
public class Dog implements Animal {
@Override
public void call() {System.out.println("汪汪汪!!!");
}
}
3. 编写配置文件
新建文件夹 META-INF/services
在文件夹下新建文件cn.zijiancode.spi.provider.Animal
对,你没看错,接口的全限定类名就是文件名
编辑文件
cn.zijiancode.spi.zoo.Dog
cn.zijiancode.spi.zoo.Cat
外面放实现类的全限定类名
3. 测试
package cn.zijiancode.spi.zoo.test;
import cn.zijiancode.spi.provider.Animal;
import java.util.ServiceLoader;
public class SpiTest {public static void main(String[] args) {
// 应用 Java 的 ServiceLoader 进行加载
ServiceLoader<Animal> load = ServiceLoader.load(Animal.class);
load.forEach(Animal::call);
}
}
测试后果:
汪汪汪!!!
喵喵喵~~
整个我的项目构造如下:
借助 SPI 了解主动拆卸
回顾一下咱们做了什么,咱们在 resources 下创立了一个文件,外面放了些实现类,而后通过 ServiceLoader
这个类加载器就把它们加载进去了。
假如有人曾经把编写配置之类的前置步骤实现了,那么咱们是不是只须要应用上面的这部分代码,就能将 Animal
无关的所有实现类调度进去。
// 应用 Java 的 ServiceLoader 进行加载
ServiceLoader<Animal> load = ServiceLoader.load(Animal.class);
load.forEach(Animal::call);
再进一步讲,如果再有人把下面这部分代码也给写了,而后把这些实现类全副注入到 Spring 容器里,那会产生什么?
哇塞,那我他喵的不是就能间接注入而后汪汪汪了吗?!
置信到这里大家心里都曾经有个谱了
找找 Spring Boot 中的配置文件
在 SPI 机制中,是通过在组件下放入一个配置文件实现的,那么 Spring Boot 是不是也这样的呢?咱们就来找一找吧。
关上 redis 的组件
咦,这外面却并没有看到无关主动拆卸的文件,难道咱们的猜测是错的嘛?
别急,其实所有 spring-boot-starter-x
的组件配置都是放在 spring-boot-autoconfigura
的组件中的
这里有个 spring.factories 的文件,翻译一下就是 spring 的工厂,咦,有点像了,关上看看
其余的咱们先不必管,能够很显著的看到最上面有个主动配置的正文,key 还是个
EnableAutoConfiguration
,开启主动配置!噢噢噢噢噢!找到了找到了!
往下翻一下,看看有没有 Redis 相干的。
再关上这个 RedisAutoConfiguration
类,看看外面是些什么代码
OMG! 破案了破案了!
当初,配置文件咱们也找到了:spring.factories
,也实锤了就是通过这个配置文件进行的主动配置。
那么,咱们来尝试还原一下案情通过:通过某种形式读取 spring.factories
文件,紧接着把外面所有的主动配置类加载到 Spring 容器中,而后就能够通过 Spring 的机制将配置类的 @Bean 注入到容器中了。
接下来,咱们就来学习一下这个 某种形式
到底是什么吧~
Spring 中的一些注入形式
阿鉴先走漏一下,这个 某种形式
,其实就是某一种注入形式,咱们先来看看 Spring 中有哪些注入形式
聊起 Spring,我可是新手了,有趣味的小伙伴能够看看我的 Spring 源码剖析系列:https://zijiancode.cn/categor…
对于注入形式,置信小伙伴必定也是:就这?
相似于 @Component,@Bean 这些,阿鉴就不说了,大家必定见过一种这样的注解:EnableXxxxx
比方:EnableAsync 开启异步,EnableTransactionManagement 开启事务
大家好不好奇这样的注解是怎么失效的?
点开看看呗
嘿,其实外面是个 Import 注解
Import 注解的 3 种应用形式
我晓得,必定有小伙伴懂得 Import 注解如何应用,然而为了关照不懂的小伙伴,阿鉴还是要讲一讲,懂的小伙伴就当温习啦
1. 一般的组件
public class Man {public Man(){System.out.println("Man was init!");
}
}
@Import({Man.class})
@Configuration
public class MainConfig {}
在配置类上应用 @Import 注解,值放入须要注入的 Bean 就能够啦
2. 实现 ImportSelector
接口
public class Child {public Child(){System.out.println("Child was init!");
}
}
public class MyImport implements ImportSelector {
@Override
public String[] selectImports(AnnotationMetadata importingClassMetadata) {return new String[]{"com.my.source.spring.start.forimport.Child"};
}
}
@Import({MyImport.class})
@Configuration
public class MainConfig {}
这种形式往 Spring 中注入的是一个 ImportSelector,当 Spring 扫描到
MyImport
,将会调用selectImports
办法,将 selectImports 中返回的 String 数组中的类注入到容器中。
3. 实现 ImportBeanDefinitionRegistrar
接口
public class Baby {public Baby(){System.out.println("Baby was init!");
}
}
public class MyImportBeanDefinitionRegistrar implements ImportBeanDefinitionRegistrar {
@Override
public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {BeanDefinition beanDefinition = new RootBeanDefinition(Baby.class);
registry.registerBeanDefinition("my-baby",beanDefinition);
}
}
@Import({MyImportBeanDefinitionRegistrar.class})
@Configuration
public class MainConfig {}
相似于第二种,当 Spring 扫描到该类时,将会调用
registerBeanDefinitions
办法,在该办法中,咱们手动往 Spring 中注入了一个 Baby 的 Bean,实践上能够通过这种形式不限量的注入任何的 Bean
SpringBootApplication 注解
咱们在应用 SpringBoot 我的项目时,用到的惟一的注解就是@SpringBootApplication
,所以咱们惟一能下手的也只有它了,关上它看看吧。
嘿!看看咱们发现了什么?EnableAutoConfiguration!妥妥的大线索呀
EnableAutoConfiguration 实质上也是通过 Import 实现的,并且 Import 了一个 Selector
让咱们瞧一瞧外面的代码逻辑吧~
selectImports
@Override
public String[] selectImports(AnnotationMetadata annotationMetadata) {if (!isEnabled(annotationMetadata)) {return NO_IMPORTS;}
AutoConfigurationEntry autoConfigurationEntry = getAutoConfigurationEntry(annotationMetadata);
return StringUtils.toStringArray(autoConfigurationEntry.getConfigurations());
}
getAutoConfigurationEntry
protected AutoConfigurationEntry getAutoConfigurationEntry(AnnotationMetadata annotationMetadata) {if (!isEnabled(annotationMetadata)) {return EMPTY_ENTRY;}
AnnotationAttributes attributes = getAttributes(annotationMetadata);
// 获取候选的配置类
List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes);
// 移除反复的配置
configurations = removeDuplicates(configurations);
// 获取到要排除的配置
Set<String> exclusions = getExclusions(annotationMetadata, attributes);
checkExcludedClasses(configurations, exclusions);
// 移除所有要排除的配置
configurations.removeAll(exclusions);
// 过滤掉不具备注入条件的配置类,通过 Conditional 注解
configurations = getConfigurationClassFilter().filter(configurations);
// 告诉主动配置相干的监听器
fireAutoConfigurationImportEvents(configurations, exclusions);
// 返回所有主动配置类
return new AutoConfigurationEntry(configurations, exclusions);
}
咱们次要看看是如何从配置文件读取的
getCandidateConfigurations
protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
// 这里就是要害,应用 SpringFactoriesLoader 加载所有配置类,是不是像咱们 SPI 的 ServicesLoader
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;
}
getSpringFactoriesLoaderFactoryClass
protected Class<?> getSpringFactoriesLoaderFactoryClass() {return EnableAutoConfiguration.class;}
联合上一步,就是加载配置文件,并且读取 key 为 EnableAutoConfiguration 的配置
loadFactoryNames
public static List<String> loadFactoryNames(Class<?> factoryType, @Nullable ClassLoader classLoader) {String factoryTypeName = factoryType.getName();
return loadSpringFactories(classLoader).getOrDefault(factoryTypeName, Collections.emptyList());
}
private static Map<String, List<String>> loadSpringFactories(@Nullable ClassLoader classLoader) {
try {
// FACTORIES_RESOURCE_LOCATION 的值为:META-INF/spring.factories
// 这步就是象征中读取 classpath 下的 META-INF/spring.factories 文件
Enumeration<URL> urls = (classLoader != null ?
classLoader.getResources(FACTORIES_RESOURCE_LOCATION) :
ClassLoader.getSystemResources(FACTORIES_RESOURCE_LOCATION));
// 接下来就是读取出文件内容,封装成 map 的操作了
result = new LinkedMultiValueMap<>();
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();
for (String factoryImplementationName : StringUtils.commaDelimitedListToStringArray((String) entry.getValue())) {result.add(factoryTypeName, factoryImplementationName.trim());
}
}
}
cache.put(classLoader, result);
return result;
}
catch (IOException ex) {
throw new IllegalArgumentException("Unable to load factories from location [" +
FACTORIES_RESOURCE_LOCATION + "]", ex);
}
}
over,前面的过滤逻辑阿鉴就不在这里说了,毕竟本节的重点是主动拆卸机制,小伙伴明确了原理就 ok 啦
ps: 因为前面的逻辑其实挺简单的,开展了说就太多啦
小结
本篇介绍了对于 SpringBoot 的主动拆卸原理,咱们先通过 SPI 机制进行了小小的热身,而后再依据 SPI 的机制进行推导 Spring 的主动拆卸原理,两头还带大家回顾了一下 @Import 注解的应用,最初胜利破案~
下节预报:实现自定义 starter
看完之后想必有所播种吧~ 想要理解更多精彩内容,欢送关注公众号:程序员阿鉴,阿鉴在公众号欢送你的到来~
集体博客空间:https://zijiancode.cn/archive…