上篇文章我们介绍了springboot启动过程中涉及的核心类及其功能,我们知道springboot相较于spring的一大特性就是自动装配,那么自动装配是怎么具体实现的呢?其实在实现自动装配上springboot采用了多种方案结合的,比如基于spring的扩展点的自动属性注入等,还有提供了一套SPI机制让程序自动可插拔的装配。本文我带大家重点 了解一下SPI机制的实现原理。
SPI(Service Provider Interface)机制是一种服务发现和加载机制。它允许开发者编写一个服务接口,然后通过在项目中使用服务提供者实现该接口的方式,实现对应的服务功能。
JDK的SPI机制通过在Classpath中的META-INF/services目录下,创建以服务接口全限定名命名的文件,文件的内容为实现该接口的具体实现类。当应用程序需要使用该服务时,JDK会自动加载并实例化配置文件中列出的实现类,并提供给应用程序使用。
在Spring Boot中,SPI机制允许开发者通过定义接口和实现类的方式,实现对应的功能扩展。通过在META-INF/spring.factories
配置文件中列出实现类,Spring Boot能够自动加载并使用这些扩展点,提供了灵活的定制和扩展能力。
Tip
:我本人在多年的开发经验中也积累了很多通用的starter,比如说通过引入我的starter修改配置文件就可以快速搭建一个web资源认证授权服务器/客户端,当然这个也是在spring-security+oauth2上进一步的封装,需要了解的可以去Git自己获取
// Git代码
https://gitee.com/yeeevip/yeee-memo/tree/master/memo-parent/memo-common/common-auth/common-platform-auth-server
https://github.com/yeeevip/yeee-memo/tree/master/memo-parent/memo-common/common-auth/common-platform-auth-server
我们会调用SpringApplication.run启动程序,通常情况下我们会在程序的主启动类上加一个 @SpringBootApplication 注解,追踪这个注解会发现它是一个复杂的聚合注解,其中内部包含了@Configuration、 @EnableAutoConfiguration ,而 @EnableAutoConfiguration 有集成了 @Import 注解,这个注解对于springboot非常重要!
// 用户定义的程序主启动类,启动程序
@SpringBootApplication
public class SpringbootExampleApplication {
public static void main(String[] args) {
SpringApplication.run(SpringbootExampleApplication.class, args);
}
}
// Springboot的主启动类,创建spring上下文
public class SpringApplication {
public ConfigurableApplicationContext run(String... args) {
ConfigurableApplicationContext context = null;
try {
...
context = createApplicationContext();
...
} catch (Throwable ex) {
...
}
}
}
springboot启动创建应用上下文后,会注册一系列的内置的后置处理器,如ConfigurationClassPostProcessor、AutowiredAnnotationBeanPostProcessor、CommonAnnotationBeanPostProcessor,其中 ConfigurationClassPostProcessor 实现了BeanFactoryPostProcessor是一个BeanFactory级别的处理器用于处理配置类
注册PostProcessor代码如下:
public class AnnotatedBeanDefinitionReader {
public AnnotatedBeanDefinitionReader(BeanDefinitionRegistry registry, Environment environment) {
...
// 注册各种后置处理器
AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);
}
}
// 注册各种后置处理器
public abstract class AnnotationConfigUtils {
public static Set<BeanDefinitionHolder> registerAnnotationConfigProcessors(BeanDefinitionRegistry registry, @Nullable Object source) {
...
if (!registry.containsBeanDefinition(CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME)) {
// 注册<配置类>处理器
RootBeanDefinition def = new RootBeanDefinition(ConfigurationClassPostProcessor.class);
def.setSource(source);
beanDefs.add(registerPostProcessor(registry, def, CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME));
}
...
return beanDefs;
}
}
springboot执行refreshContext刷新上下文,本质还是spring上下文的refresh方法,这个方法是spring生命周期的关键核心代码,spring生命周期的大部分扩展点都是在这里执行的。其中在执行容器中未实例化初始化的bean定义之前会执行内置的、用户自定义的所有注册的beanFactory后置处理器,这里会执行到ConfigurationClassPostProcessor这个配置类处理器
Tip
:关于Spring的扩展点大概有13个,其中包括一些后置处理器,具体怎么使用需要了解的可以去Git自己获取,这里不再细说
// Git代码
https://gitee.com/yeeevip/yeee-memo/tree/master/learn-example/spring-boot-example/src/main/java/vip/yeee/memo/demo/springboot/extpoint
https://github.com/yeeevip/yeee-memo/tree/master/learn-example/spring-boot-example/src/main/java/vip/yeee/memo/demo/springboot/extpoint
刷新上下文代码如下:
// Springboot调用refreshContext来执行父类的refresh方法
public class SpringApplication {
public ConfigurableApplicationContext run(String... args) {
...
try {
...
// 刷新上下文
refreshContext(context);
...
} catch (Throwable ex) {
throw new IllegalStateException(ex);
}
...
return context;
}
}
// 调用spring的AbstractApplicationContext的refresh()方法刷新
public abstract class AbstractApplicationContext extends DefaultResourceLoader implements ConfigurableApplicationContext {
public void refresh() throws BeansException, IllegalStateException {
...
try {
...
// 执行所有注册的BeanFactory后置处理器
invokeBeanFactoryPostProcessors(beanFactory);
...
// 实例化、初始化所有的单例Bean
finishBeanFactoryInitialization(beanFactory);
} catch (BeansException ex) {
...
}
}
}
spring在执行到BeanFactory处理器的生命周期时会执行到ConfigurationClassPostProcessor这个处理器,执行具体处理逻辑,如配置类上的@PropertySource、@ComponentScan、@Import、@ImportResource、@Bean等注解都会有相应的处理,目的就是将定义的BeanDefinition注册到BeanFactory容器中以便于最终的初始化。
由于用@SpringBootApplication这个注解标记的类即SpringbootExampleApplication.class本身也是个配置类,这里的话就会处理这个主启动类。
处理配置类的代码:
public class ConfigurationClassPostProcessor implements BeanDefinitionRegistryPostProcessor {
public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
// 这里会有我们程序的主启动配置类,也就是SpringbootExampleApplication.class
List<BeanDefinitionHolder> configCandidates = new ArrayList<>();
...
// 转换每个配置类
ConfigurationClassParser parser = new ConfigurationClassParser();
...
do {
...
// 处理配置类
parser.parse(candidates);
...
} while (!candidates.isEmpty());
}
}
// 调用parse方法后会执行到doProcessConfigurationClass
class ConfigurationClassParser {
protected final SourceClass doProcessConfigurationClass(ConfigurationClass configClass, SourceClass sourceClass, Predicate<String> filter) {
// 处理配置类的@PropertySource注解
...
processPropertySource(propertySource);
...
// 处理配置类的@ComponentScan注解
...
Set<BeanDefinitionHolder> scannedBeanDefinitions = this.componentScanParser.parse(componentScan, sourceClass.getMetadata().getClassName());
...
// 处理配置类的@Import注解,这里就是SPI机制核心实现逻辑了
processImports(configClass, sourceClass, getImports(sourceClass), filter, true);
// 处理配置类的@ImportResource注解
...
String resolvedResource = this.environment.resolveRequiredPlaceholders(resource);
configClass.addImportedResource(resolvedResource, readerClass);
...
// 处理配置类的@Bean注解
...
Set<MethodMetadata> beanMethods = retrieveBeanMethodMetadata(sourceClass);
...
}
}
processImports这个方法会专门处理 @Import 这个注解,进入方法发现会执行getImports方法获得@Import导入的类AutoConfigurationImportSelector.class,由于它实现了DeferredImportSelector,所以程序会执行deferredImportSelectorHandler.handle去处理这个Selector;其实这里也还没有真正开始处理,最终的处理是在调用deferredImportSelectorHandler.process()发起的。
看代码:
class ConfigurationClassParser {
private void processImports(ConfigurationClass configClass, SourceClass currentSourceClass, Collection<SourceClass> importCandidates,...) {
...
for (SourceClass candidate : importCandidates) {
if (candidate.isAssignable(ImportSelector.class)) {
...
// 判断当前的导入的类是不是DeferredImportSelector的子类
if (selector instanceof DeferredImportSelector) {
// 是DeferredImportSelector的子类的话由deferredImportSelectorHandler去处理
this.deferredImportSelectorHandler.handle(configClass, (DeferredImportSelector) selector);
}
...
}
...
}
}
public void parse(Set<BeanDefinitionHolder> configCandidates) {
...
// 这里发起真正处理Selector的逻辑
this.deferredImportSelectorHandler.process();
}
}
4.1
读取项目路径下所有依赖中的spring.factories文件,加载需要自动配置的类
跟踪代码发现,执行process()后会执行handler.processGroupImports(),进而会执行grouping.getImports(),这个方法会用类加载器扫码程序classpath下所有jar中的spring.factories文件,然后会得到所有用EnableAutoConfiguration属性标记的自动配置类
class ConfigurationClassParser {
public Iterable<Group.Entry> getImports() {
for (DeferredImportSelectorHolder deferredImport : this.deferredImports) {
// 会扫描jar下的spring.factories中的自动配置类
this.group.process(deferredImport.getConfigurationClass().getMetadata(),
deferredImport.getImportSelector());
}
return this.group.selectImports();
}
}
// 具体扫描spring.factories的实现在AutoConfigurationImportSelector.process
public class AutoConfigurationImportSelector implements DeferredImportSelector,... {
@Override
public void process(AnnotationMetadata annotationMetadata, DeferredImportSelector deferredImportSelector) {
// getAutoConfigurationEntry这个方法执行
AutoConfigurationEntry autoConfigurationEntry = (deferredImportSelector).getAutoConfigurationEntry(annotationMetadata);
...
}
protected AutoConfigurationEntry getAutoConfigurationEntry(AnnotationMetadata annotationMetadata) {
...
// 这里会调用SpringFactoriesLoader.loadFactoryNames读取spring.factories文件
List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes);
...
}
protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
// 读取key为EnableAutoConfiguration.class的所有自动配置类
List<String> configurations = SpringFactoriesLoader.loadFactoryNames(getSpringFactoriesLoaderFactoryClass(),getBeanClassLoader());
}
protected Class<?> getSpringFactoriesLoaderFactoryClass() {
return EnableAutoConfiguration.class;
}
}
4.2
针对所有扫描到的自动配置类再次执行配置类处理逻辑
上面已经从spring.factories中扫描到了所有配置类,紧接着程序同样会执行配置类处理逻辑,具体处理逻辑同第4节开始,同样也是处理这个配置类中的各种注解/方法,目的就是为了将这些BeanDefinition加入到spring容器中以便于最终初始化。
4.3
将所有通过配置类处理过符合条件的BeanDefinition注册到spring容器中
执行完针对配置类的处理转换后,也就是执行完parse方法后,会再调用reader.loadBeanDefinitions用来把配置类处理后符合条件的BeanDefinition注册到spring容器
看代码:
public class ConfigurationClassPostProcessor implements BeanDefinitionRegistryPostProcessor {
public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
...
do {
...
// 处理配置类
parser.parse(candidates);
...
// parse转换处理完配置类后,然后会把所有处理过符合条件的注册到spring容器
this.reader.loadBeanDefinitions(configClasses);
...
} while (!candidates.isEmpty());
}
}
这里spring会把通过各种方式注册的单例BeanDefinition,如通过注解@Component、@Service标记的Bean,以及我们本文探讨的重点通过SPI机制的导入的Bean进行最终的实例化/初始化。具体的处理过程也是spring的核心之一,有兴趣的小伙伴可以看一下源码,这里不详细介绍了。
public abstract class AbstractApplicationContext extends DefaultResourceLoader implements ConfigurableApplicationContext {
public void refresh() throws BeansException, IllegalStateException {
...
try {
...
// 执行所有注册的BeanFactory后置处理器
invokeBeanFactoryPostProcessors(beanFactory);
...
// 实例化、初始化所有的单例Bean
finishBeanFactoryInitialization(beanFactory);
} catch (BeansException ex) {
...
}
}
}
好啦,今天的内容就到这里了,通过以上代码分析,带大家了解了springboot的SPI机制实现的原理,当然本文分析的可能还是比较片面,毕竟springboot在实现自动装配上还不止是SPI一个方案,它还涉及了很多复杂的处理。
文章中如果有问题疑问欢迎小伙伴们提问或者给我指点一下哦,大家一起探讨一下!
下面这个是我多年经验积累的一套脚手架, 里面集成了各种通用的自定义starter,同时也提供了互联网项目中各种中间件/框架的使用demo,有兴趣的小伙伴可以git看看哦,并且欢迎大佬们指点!!!
// Git代码
https://gitee.com/yeeevip/yeee-memo
https://github.com/yeeevip/yeee-memo