SpringBoot自动配置

最新推荐文章于 2024-07-24 22:23:04 发布
最新推荐文章于 2024-07-24 22:23:04 发布
阅读量2.3k 收藏 26
点赞数 38
文章标签： spring springboot
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u014474768/article/details/137037915
版权
  1. @EnableAutoConfiguration源码解析
  2. SpringBoot常用条件注解源码解析
  3. SpringBoot之Mybatis自动配置源码解析
  4. SpringBoot之AOP自动配置源码解析
  5. SpringBoot Jar包启动过程源码解析

SpringBoot2.6.6源码地址：SpringBoot-2.6.6: SpringBoot2.6.6

注解详解

@SpringBootConfiguration

相当于@Component注解

如果解析当前bean的时候spring容器里没有User这个bean就符合条件，也就是如果程序员定义了User这个bean，那这个User就不生效了

@Import注解

可以通过@Import注解来导入配置类和spring.factories一个作用

讲道理按上面的说法，生效的应该是MyApplication这个bean，但实际上会报错。

原因：先处理的上面的@Import注解，此时容器里还没User，所以Bean注解在处理User的时候，已经有名字User的bean了，所以报错

ImportSelector接口

假如我现在导入了实现ImportSelector的一个类，然后实现先扣的selectImports方法，然后返回一个数组，【可以返回很多的自动配置类】

还是会先解析这个自动配置类【ZhouyuAutoConfiguration】再去解析@Bean

成功把

DeferredImportSelector接口

DeferredImportSelector和ImportSelector的区别在于：

  1. 在解析ImportSelector时，所导入的配置类会被直接解析，而DeferredImportSelector导入的配置类会延迟进行解析（延迟在其他配置类都解析完之后包括Application解析完才会去解析，先解析程序员定义的@Bean）

  1. DeferredImportSelector支持分组，可以实现getImportGroup方法以及定义Group对象，就相当于指定了DeferredImportSelector所导入进来的配置类所属的组，比如SpringBoot就把所有自动配置类单独做了分组AutoConfigurationGroup

实现了Group接口

加了getImportGroup方法，selectImports方法就不执行了

如果上面的getImportGroup方法返回不为null，就会执行下面的process方法，然后在执行selectImports方法

@EnableAutoConfiguration

里面就包含了

@Import AutoConfigurationImportSelector类

导入了AutoConfigurationImportSelector这个类，找自动配置类，过滤自动配置类，返回给spring容器

实现了DeferredImportSelector接口

也返回了AutoConfigurationGroup类【静态内部类】==》解析Spring.factories文件，拿到自动配置类的名字，去过滤，返回生效的自动配置类

@AutoConfigurationPackage

也用了@Import注解，导入了Registrar

解析完这个注解会调用registerBeanDefinitions这个方法，拿到扫描路径，com.zkc，把包路径变成个bean注册到spring容器中【给Mybatis用的】

这里是Mybatis源码，也就是说设置Mybatis要扫描的路径

那为什么此时去掉@Mapper注解就扫描不到这个mapper了？【上面一定要加@Mapper才会扫描到。。Mybatis加的限定条件】

如果用的MapperScan注解，它扫描时候就不会限定上面要有@Mapper注解了，且重复扫描了。所以这个其实没必要用了，这个注解

@ComponentScan注解

排除过滤器TypeExcludeFilter和AutoConfigurationExcludeFilter这两个类

AutoConfigurationExcludeFilter：

去springFactories找到所有的自动配置类，和加了@Configuration的配置类，都过滤掉了，因为前面自动配置类已经处理了，这边无需重复处理。

TypeExcludeFilter：

相当于扩展点，到spring容器中找到TypeExcludeFilter类型的bean，自定义排除逻辑。

可以自定义过滤逻辑，排除掉bean，想要生效，必须在扫描之前就注册进spring容器里

解决方案：

定义容器初始化器，实现initialize方法

注册排除过滤器到spring容器中

同时还要加到spring.factories中才能生效

常用条件注解

SpringBoot中的常用条件注解有：

  1. ConditionalOnBean：是否存在某个某类或某个名字的Bean
  2. ConditionalOnMissingBean：是否缺失某个某类或某个名字的Bean
  3. ConditionalOnSingleCandidate：是否符合指定类型的Bean只有一个
  4. ConditionalOnClass：是否存在某个类
  5. ConditionalOnMissingClass：是否缺失某个类
  6. ConditionalOnExpression：指定的表达式返回的是true还是false
  7. ConditionalOnJava：判断Java版本
  8. ConditionalOnWebApplication：当前应用是不是一个Web应用
  9. ConditionalOnNotWebApplication：当前应用不是一个Web应用
  10. ConditionalOnProperty：Environment中是否存在某个属性

当然我们也可以利用@Conditional来自定义条件注解。

条件注解是可以写在类上和方法上的，如果某个条件注解写在了自动配置类上，那该自动配置类会不会生效就要看当前条件能不能符合，或者条件注解写在某个@Bean修饰的方法上，那这个Bean生不生效就看当前条件符不符合。

具体原理是：

  1. Spring在解析某个自动配置类时，会先检查该自动配置类上是否有条件注解，如果有，则进一步判断该条件注解所指定的条件当前能不能满足，如果满足了则继续解析该配置类，如果不满足则不进行解析了，也就是配置类所定义的Bean都得不到解析，也就是相当于没有这些Bean了。
  2. 同理，Spring在解析某个@Bean的方法时，也会先判断方法上是否有条件注解，然后进行解析，如果不满足条件，则该Bean不会生效

我们可以发现，SpringBoot的自动配置，实际上就是SpringBoot的源码中预先写好了一些配置类，预先定义好了一些Bean，我们在用SpringBoot时，这些配置类就已经在我们项目的依赖中了，而这些自动配置类或自动配置Bean到底生不生效，就看具体所指定的条件了。

自定义条件注解

SpringBoot中众多的条件注解，都是基于Spring中的@Conditional来实现的，所以我们先来用一下@Conditional注解。

先来看下@Conditional注解的定义：
 

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Conditional {
	
	/**
	* All {@link Condition} classes that must {@linkplain Condition#matches match}
	* in order for the component to be registered.
	*/
	Class<? extends Condition>[] value();
	
}

根据定义我们在用@Conditional注解时，需要指定一个或多个Condition的实现类，所以我们先来提供一个实现类：

public class ZhouyuCondition implements Condition {

	@Override
	public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
		return false;
	}

}

很明显，我们可以在matches方法中来定义条件逻辑：

  1. ConditionContext：表示条件上下文，可以通过ConditionContext获取到当前的类加载器、BeanFactory、Environment环境变量对象
  2. AnnotatedTypeMetadata：表示当前正在进行条件判断的Bean所对应的类信息，或方法信息（比如@Bean定义的一个Bean），可以通过AnnotatedTypeMetadata获取到当前类或方法相关的信息，从而就可以拿到条件注解的信息，当然如果一个Bean上使用了多个条件注解，那么在解析过程中都可以获取到，同时也能获取Bean上定义的其他注解信息

@ConditionalOnClass的底层工作原理

先来看一个案例：

@Configuration
@ConditionalOnClass(name = "com.zhouyu.Jetty")
@ConditionalOnMissingClass(value = "com.zhouyu.Tomcat")
public class ZhouyuConfiguration {


}

我们在ZhouyuConfiguration这个类上使用了两个条件注解：

  1. @ConditionalOnClass(name = "com.zhouyu.Jetty")：条件是项目依赖中存在"com.zhouyu.Jetty"这个类，则表示符合条件
  2. @ConditionalOnMissingClass(value = "com.zhouyu.Tomcat")：条件是项目依赖中不存在"com.zhouyu.Tomcat"这个类，则表示符合条件

这两个注解对应的都是@Conditional(OnClassCondition.class)，那在OnClassCondition类中是如何对这两个注解进行区分的呢？

Spring在解析到ZhouyuConfiguration这个配置时，发现该类上用到了条件注解就会进行条件解析，相关源码如下：


// 这是Spring中的源码，不是SpringBoot中的
for (Condition condition : conditions) {
	ConfigurationPhase requiredPhase = null;
	if (condition instanceof ConfigurationCondition) {
		requiredPhase = ((ConfigurationCondition) condition).getConfigurationPhase();
	}
	
	// 重点在这
	if ((requiredPhase == null || requiredPhase == phase) && !condition.matches(this.context, metadata)) {
		return true;
	}
}

conditions中保存了两个OnClassCondition对象，这段代码会依次调用OnClassCondition对象的matches方法进行条件匹配，一旦某一个条件不匹配就不会进行下一个条件的判断了，这里return的是true，但是这段代码所在的方法叫做shouldSkip，所以true表示忽略。

我们继续看OnClassCondition的matches()方法的实现。

OnClassCondition类继承了FilteringSpringBootCondition，FilteringSpringBootCondition类又继承了SpringBootCondition，而SpringBootCondition实现了Condition接口，matches()方法也是在SpringBootCondition这个类中实现的：

@Override
public final boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
	// 获取当前解析的类名或方法名
	String classOrMethodName = getClassOrMethodName(metadata);
	try {
		// 进行具体的条件匹配，ConditionOutcome表示匹配结果
		ConditionOutcome outcome = getMatchOutcome(context, metadata);
		
		// 日志记录匹配结果
		logOutcome(classOrMethodName, outcome);
		recordEvaluation(context, classOrMethodName, outcome);
		
		// 返回true或false
		return outcome.isMatch();
	}
	catch (NoClassDefFoundError ex) {
		// ...
	}
	catch (RuntimeException ex) {
	    // ...
	}
}

所以具体的条件匹配逻辑在getMatchOutcome方法中，而SpringBootCondition类中的getMatchOutcome方法是一个抽象方法，具体的实现逻辑就在子类OnClassCondition中：

@Override
public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {
	ClassLoader classLoader = context.getClassLoader();
	ConditionMessage matchMessage = ConditionMessage.empty();
	
	// 拿到ConditionalOnClass注解中的value值，也就是要判断是否存在的类名
	List<String> onClasses = getCandidates(metadata, ConditionalOnClass.class);
	if (onClasses != null) {
		// 判断onClasses中不存在的类
		List<String> missing = filter(onClasses, ClassNameFilter.MISSING, classLoader);
		// 如果有缺失的类，那就表示不匹配
		if (!missing.isEmpty()) {
			return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnClass.class)
											.didNotFind("required class", "required classes").items(Style.QUOTE, missing));
		}
		// 否则就表示匹配
		matchMessage = matchMessage.andCondition(ConditionalOnClass.class)
			.found("required class", "required classes")
			.items(Style.QUOTE, filter(onClasses, ClassNameFilter.PRESENT, classLoader));
	}
	
	// 和上面类似，只不过是判断onMissingClasses是不是全部缺失，如果是则表示匹配
	List<String> onMissingClasses = getCandidates(metadata, ConditionalOnMissingClass.class);
	if (onMissingClasses != null) {
		List<String> present = filter(onMissingClasses, ClassNameFilter.PRESENT, classLoader);
		if (!present.isEmpty()) {
			return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnMissingClass.class)
											.found("unwanted class", "unwanted classes").items(Style.QUOTE, present));
		}
		matchMessage = matchMessage.andCondition(ConditionalOnMissingClass.class)
			.didNotFind("unwanted class", "unwanted classes")
			.items(Style.QUOTE, filter(onMissingClasses, ClassNameFilter.MISSING, classLoader));
	}
	return ConditionOutcome.match(matchMessage);
}

在getMatchOutcome方法中的逻辑为：

  1. 如果类或方法上有@ConditionalOnClass注解，则获取@ConditionalOnClass注解中的value属性，也就是要判断是否存在的类名
  2. 利用ClassNameFilter.MISSING来判断这些类是否缺失，把缺失的类的类名存入missing集合
  3. 如果missing不为空，则表示有类缺失，则表示不匹配，并利用ConditionMessage记录哪些类是缺失的，直接return，表示条件不匹配
  4. 否则，则表示条件匹配，继续执行代码
  5. 如果类或方法上有ConditionalOnMissingClass注解，则获取ConditionalOnMissingClass注解中的value属性，也就是要判断是否缺失的类名
  6. 利用ClassNameFilter.PRESENT来判断这些类是否存在，把存在的类的类名存入present集合
  7. 如果present不为空，则表示有类存在，则表示不匹配，并利用ConditionMessage记录哪些类是存在的，直接return，表示条件不匹配
  8. 否则，则表示条件匹配，继续执行代码
  9. return，表示条件匹配

因为ConditionalOnClass注解和ConditionalOnMissingClass注解的逻辑是比较类似的，所以在源码中都是在OnClassCondition这个类中实现的，假如一个类上即有@ConditionalOnClass，也有@ConditionalOnMissingClass，比如以下代码：

@Configuration
@ConditionalOnClass(Tomcat.class)
@ConditionalOnMissingClass(value = "com.zhouyu.Tomcat")
public class ZhouyuConfiguration {


}

  1. 如果@ConditionalOnClass条件匹配、@ConditionalOnMissingClass条件也匹配，那么getMatchOutcome方法会执行两次
  2. 如果@ConditionalOnClass条件不匹配，那么getMatchOutcome方法会执行一次
  3. 如果@ConditionalOnClass条件匹配、@ConditionalOnMissingClass条件不匹配，那么getMatchOutcome方法也只会执行一次，因为在getMatchOutcome方法处理了这种情况

上面提到的ClassNameFilter.MISSING和ClassNameFilter.PRESENT也比较简单，代码如下：

protected enum ClassNameFilter {

		PRESENT {

			@Override
			public boolean matches(String className, ClassLoader classLoader) {
				return isPresent(className, classLoader);
			}

		},

		MISSING {

			@Override
			public boolean matches(String className, ClassLoader classLoader) {
				return !isPresent(className, classLoader);
			}

		};

		abstract boolean matches(String className, ClassLoader classLoader);

		static boolean isPresent(String className, ClassLoader classLoader) {
			if (classLoader == null) {
				classLoader = ClassUtils.getDefaultClassLoader();
			}
			try {
				resolve(className, classLoader);
				return true;
			}
			catch (Throwable ex) {
				return false;
			}
		}

	}
protected static Class<?> resolve(String className, ClassLoader classLoader) throws ClassNotFoundException {
	if (classLoader != null) {
		return Class.forName(className, false, classLoader);
	}
	return Class.forName(className);
}

主要就是用类加载器，来判断类是否存在。

@ConditionalOnBean的底层工作原理

@ConditionalOnBean和@ConditionalOnClass的底层实现应该是差不多的，一个是判断Bean存不存在，一个是判断类存不存在，事实上也确实差不多。

首先@ConditionalOnBean和@ConditionalOnMissingBean对应的都是OnBeanCondition类，OnBeanCondition类也是继承了SpringBootCondition，所以SpringBootCondition类中的getMatchOutcome方法才是匹配逻辑：

@Override
public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {
	ConditionMessage matchMessage = ConditionMessage.empty();
	MergedAnnotations annotations = metadata.getAnnotations();
	
	// 如果存在ConditionalOnBean注解
	if (annotations.isPresent(ConditionalOnBean.class)) {
		Spec<ConditionalOnBean> spec = new Spec<>(context, metadata, annotations, ConditionalOnBean.class);
		MatchResult matchResult = getMatchingBeans(context, spec);
		
		// 如果某个Bean不存在
		if (!matchResult.isAllMatched()) {
			String reason = createOnBeanNoMatchReason(matchResult);
			return ConditionOutcome.noMatch(spec.message().because(reason));
		}
		
		// 所有Bean都存在
		matchMessage = spec.message(matchMessage).found("bean", "beans").items(Style.QUOTE,
																			   matchResult.getNamesOfAllMatches());
	}
	
	// 如果存在ConditionalOnSingleCandidate注解
	if (metadata.isAnnotated(ConditionalOnSingleCandidate.class.getName())) {
		Spec<ConditionalOnSingleCandidate> spec = new SingleCandidateSpec(context, metadata, annotations);
		MatchResult matchResult = getMatchingBeans(context, spec);
		
		// Bean不存在
		if (!matchResult.isAllMatched()) {
			return ConditionOutcome.noMatch(spec.message().didNotFind("any beans").atAll());
		}
		
		// Bean存在
		Set<String> allBeans = matchResult.getNamesOfAllMatches();
		
		// 如果只有一个
		if (allBeans.size() == 1) {
			matchMessage = spec.message(matchMessage).found("a single bean").items(Style.QUOTE, allBeans);
		}
		else {
			// 如果有多个
			List<String> primaryBeans = getPrimaryBeans(context.getBeanFactory(), allBeans,
														spec.getStrategy() == SearchStrategy.ALL);
			
			// 没有主Bean，那就不匹配
			if (primaryBeans.isEmpty()) {
				return ConditionOutcome.noMatch(
					spec.message().didNotFind("a primary bean from beans").items(Style.QUOTE, allBeans));
			}
			// 有多个主Bean，那就不匹配
			if (primaryBeans.size() > 1) {
				return ConditionOutcome
					.noMatch(spec.message().found("multiple primary beans").items(Style.QUOTE, primaryBeans));
			}
			
			// 只有一个主Bean
			matchMessage = spec.message(matchMessage)
				.found("a single primary bean '" + primaryBeans.get(0) + "' from beans")
				.items(Style.QUOTE, allBeans);
		}
	}
	
	// 存在ConditionalOnMissingBean注解
	if (metadata.isAnnotated(ConditionalOnMissingBean.class.getName())) {
		Spec<ConditionalOnMissingBean> spec = new Spec<>(context, metadata, annotations,
														 ConditionalOnMissingBean.class);
		MatchResult matchResult = getMatchingBeans(context, spec);
		
		//有任意一个Bean存在，那就条件不匹配
		if (matchResult.isAnyMatched()) {
			String reason = createOnMissingBeanNoMatchReason(matchResult);
			return ConditionOutcome.noMatch(spec.message().because(reason));
		}
		
		// 都不存在在，则匹配
		matchMessage = spec.message(matchMessage).didNotFind("any beans").atAll();
	}
	return ConditionOutcome.match(matchMessage);
}

逻辑流程为：

  1. 当前在解析的类或方法上，是否有@ConditionalOnBean注解，如果有则生成对应的Spec对象，该对象中包含了用户指定的，要判断的是否存在的Bean的类型
  2. 调用getMatchingBeans方法进行条件判断，MatchResult为条件判断结果
  3. 只要判断出来某一个Bean不存在，则return，表示条件不匹配
  4. 只要所有Bean都存在，则继续执行下面代码
  5. 当前在解析的类或方法上，是否有@ConditionalOnSingleCandidate注解，如果有则生成对应的SingleCandidateSpec对象，该对象中包含了用户指定的，要判断的是否存在的Bean的类型（只能指定一个类型），并且该类型的Bean只能有一个
  6. 调用getMatchingBeans方法进行条件判断，MatchResult为条件判断结果
  7. 指定类型的Bean如果不存在，则return，表示条件不匹配
  8. 如果指定类型的Bean存在，但是存在多个，那就看是否存在主Bean（加了@primary注解的Bean），并且只能有一个主Bean，如果没有，则return，表示条件不匹配
  9. 如果只有一个主Bean，则表示条件匹配，继续执行下面代码
  10. 当前在解析的类或方法上，是否有@ConditionalOnMissingBean注解，如果有则生成对应的Spec对象，该对象中包含了用户指定的，要判断的是否缺失的Bean的类型
  11. 调用getMatchingBeans方法进行条件判断，MatchResult为条件判断结果
  12. 只要有任意一个Bean存在，则return，表示条件不匹配
  13. 都存在，则表示条件匹配
  14. 结束

getMatchingBeans方法中会利用BeanFactory去获取指定类型的Bean，如果没有指定类型的Bean，则会将该类型记录在MatchResult对象的unmatchedTypes集合中，如果有该类型的Bean，则会把该Bean的beanName记录在MatchResult对象的matchedNames集合中，所以MatchResult对象中记录了，哪些类没有对应的Bean，哪些类有对应的Bean。

@ConditionalOnClass和@ConditionalOnBean，这两个条件注解的工作原理就分析到这，总结以下流程就是：

  1. Spring在解析某个配置类，或某个Bean定义时
  2. 如果发现它们上面用到了条件注解，就会取出所有的条件的条件注解，并生成对应的条件对象，比如OnBeanCondition对象、OnClassCondition对象
  3. 从而依次调用条件对象的matches方法，进行条件匹配，看是否符合条件
  4. 而条件匹配逻辑中，会拿到@ConditionalOnClass和@ConditionalOnBean等条件注解的信息，比如要判断哪些类存在、哪些Bean存在
  5. 然后利用ClassLaoder、BeanFactory来进行判断
  6. 最后只有所有条件注解的条件都匹配，那么当前配置类或Bean定义才算符合条件

源码会有点难，还希望大家耐点性子，多看多调试源码。

Starter机制

那SpringBoot中的Starter和自动配置又有什么关系呢？

其实首先要明白一个Starter，就是一个Maven依赖，当我们在项目的pom.xml文件中添加某个Starter依赖时，其实就是简单的添加了很多其他的依赖，比如：

  1. spring-boot-starter-web：引入了spring-boot-starter、spring-boot-starter-json、spring-boot-starter-tomcat等和Web开发相关的依赖包
  2. spring-boot-starter-tomcat：引入了tomcat-embed-core、tomcat-embed-el、tomcat-embed-websocket等和Tomcat相关的依赖包
  3. ...

如果硬要把Starter机制和自动配置联系起来，那就是通过@ConditionalOnClass这个条件注解，因为这个条件注解的作用就是用来判断当前应用的依赖中是否存在某个类或某些类，比如：

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass({ Servlet.class, Tomcat.class, UpgradeProtocol.class })
@ConditionalOnMissingBean(value = ServletWebServerFactory.class, search = SearchStrategy.CURRENT)
static class EmbeddedTomcat {
    
    @Bean
    TomcatServletWebServerFactory tomcatServletWebServerFactory(
        ObjectProvider<TomcatConnectorCustomizer> connectorCustomizers,
        ObjectProvider<TomcatContextCustomizer> contextCustomizers,
        ObjectProvider<TomcatProtocolHandlerCustomizer<?>> protocolHandlerCustomizers) {
        TomcatServletWebServerFactory factory = new TomcatServletWebServerFactory();
        
        // orderedStream()调用时会去Spring容器中找到TomcatConnectorCustomizer类型的Bean，默认是没有的，程序员可以自己定义
        factory.getTomcatConnectorCustomizers()
            .addAll(connectorCustomizers.orderedStream().collect(Collectors.toList()));
        factory.getTomcatContextCustomizers()
            .addAll(contextCustomizers.orderedStream().collect(Collectors.toList()));
        factory.getTomcatProtocolHandlerCustomizers()
            .addAll(protocolHandlerCustomizers.orderedStream().collect(Collectors.toList()));
        return factory;
    }
    
}

上面代码中就用到了@ConditionalOnClass，用来判断项目中是否存在Servlet.class、Tomcat.class、UpgradeProtocol.class这三个类，如果存在就满足当前条件，如果项目中引入了spring-boot-starter-tomcat，那就有这三个类，如果没有spring-boot-starter-tomcat那就可能没有这三个类（除非你自己单独引入了Tomcat相关的依赖）。

所以这就做到了，如果我们在项目中要用Tomcat，那就依赖spring-boot-starter-web就够了，因为它默认依赖了spring-boot-starter-tomcat，从而依赖了Tomcat，从而Tomcat相关的Bean能生效。

而如果不想用Tomcat，那就得这么写：

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-web</artifactId>
	<exclusions>
		<exclusion>
			<groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-tomcat</artifactId>
      </exclusion>
	</exclusions>
</dependency>

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-jetty</artifactId>
</dependency>

得把spring-boot-starter-tomcat给排除掉，再添加上spring-boot-starter-jetty的依赖，这样Tomcat的Bean就不会生效，Jetty的Bean就能生效，从而项目中用的就是Jetty。

Spring Boot Tomcat自动配置

通过前面我们会SpringBoot的自动配置机制、Starter机制、启动过程的底层分析，我们拿一个实际的业务案例来串讲一下，那就是SpringBoot和Tomcat的整合。

我们知道，只要我们的项目添加的starter为：spring-boot-starter-web，那么我们启动项目时，SpringBoot就会自动启动一个Tomcat。

那么这是怎么做到的呢？

首先我们可以发现，在spring-boot-starter-web这个starter中，其实简介的引入了spring-boot-starter-tomcat这个starter，这个spring-boot-starter-tomcat又引入了tomcat-embed-core依赖，所以只要我们项目中依赖了spring-boot-starter-web就相当于依赖了Tomcat。

然后在SpringBoot众多的自动配置类中，有一个自动配置类叫做ServletWebServerFactoryAutoConfiguration，定义为：

@Configuration(proxyBeanMethods = false)
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
@ConditionalOnClass(ServletRequest.class)
@ConditionalOnWebApplication(type = Type.SERVLET)
@EnableConfigurationProperties(ServerProperties.class)
@Import({ ServletWebServerFactoryAutoConfiguration.BeanPostProcessorsRegistrar.class,
		ServletWebServerFactoryConfiguration.EmbeddedTomcat.class,
		ServletWebServerFactoryConfiguration.EmbeddedJetty.class,
		ServletWebServerFactoryConfiguration.EmbeddedUndertow.class })
public class ServletWebServerFactoryAutoConfiguration {
	// ...
}

首先看这个自动配置类所需要的条件：

  1. @ConditionalOnClass(ServletRequest.class)：表示项目依赖中要有ServletRequest类（server api）
  2. @ConditionalOnWebApplication(type = Type.SERVLET)：表示项目应用类型得是SpringMVC（讲启动过程的时候就知道如何判断一个SpringBoot应用的类型了）

在上面提到的spring-boot-starter-web中，其实还间接的引入了spring-web、spring-webmvc等依赖，这就使得第二个条件满足，而对于第一个条件的ServletRequest类，虽然它是Servlet规范中的类，但是在我们所依赖的tomcat-embed-core这个jar包中是存在这个类的，这是因为Tomcat在自己的源码中把Servlet规范中的一些代码也包含进去了，比如：

这就使得ServletWebServerFactoryAutoConfiguration这个自动配置的两个条件都符合，那么Spring就能去解析它，一解析它就发现这个自动配置类Import进来了三个类：

  1. ServletWebServerFactoryConfiguration.EmbeddedTomcat.class
  2. ServletWebServerFactoryConfiguration.EmbeddedJetty.class
  3. ServletWebServerFactoryConfiguration.EmbeddedUndertow.class

很明显，Import进来的这三个类应该是差不多，我们看EmbeddedTomcat这个类：

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass({ Servlet.class, Tomcat.class, UpgradeProtocol.class })
@ConditionalOnMissingBean(value = ServletWebServerFactory.class, search = SearchStrategy.CURRENT)
static class EmbeddedTomcat {
	
	@Bean
	TomcatServletWebServerFactory tomcatServletWebServerFactory(
		ObjectProvider<TomcatConnectorCustomizer> connectorCustomizers,
		ObjectProvider<TomcatContextCustomizer> contextCustomizers,
		ObjectProvider<TomcatProtocolHandlerCustomizer<?>> protocolHandlerCustomizers) {
		TomcatServletWebServerFactory factory = new TomcatServletWebServerFactory();
		
		// orderedStream()调用时会去Spring容器中找到TomcatConnectorCustomizer类型的Bean，默认是没有的，程序员可以自己定义
		factory.getTomcatConnectorCustomizers()
			.addAll(connectorCustomizers.orderedStream().collect(Collectors.toList()));
		factory.getTomcatContextCustomizers()
			.addAll(contextCustomizers.orderedStream().collect(Collectors.toList()));
		factory.getTomcatProtocolHandlerCustomizers()
			.addAll(protocolHandlerCustomizers.orderedStream().collect(Collectors.toList()));
		return factory;
	}
	
}

可以发现这个类是一个配置类，所以Spring也会来解析它，不过它也有两个条件：

  1. @ConditionalOnClass({ Servlet.class, Tomcat.class, UpgradeProtocol.class })：项目依赖中要有Servlet.class、Tomcat.class、UpgradeProtocol.class这三个类，这个条件比较容易理解，项目依赖中有Tomcat的类，那这个条件就符合。
  2. @ConditionalOnMissingBean(value = ServletWebServerFactory.class, search = SearchStrategy.CURRENT)，项目中没有ServletWebServerFactory类型的Bean，因为这个配置类的内部就是定义了一个TomcatServletWebServerFactory类型的Bean，TomcatServletWebServerFactory实现了ServletWebServerFactory接口，所以这个条件注解的意思就是，如果程序员自己没有定义ServletWebServerFactory类型的Bean，那么就符合条件，不然，如果程序员自己定义了ServletWebServerFactory类型的Bean，那么条件就不符合，也就导致SpringBoot给我们定义的TomcatServletWebServerFactory这个Bean就不会生效，最终生效的就是程序员自己定义的。

所以，通常只要我们项目依赖中有Tomcat依赖，那就符合条件，那最终Spring容器中就会有TomcatServletWebServerFactory这个Bean。

对于另外的EmbeddedJetty和EmbeddedUndertow，也差不多，都是判断项目依赖中是否有Jetty和Undertow的依赖，如果有，那么对应在Spring容器中就会存在JettyServletWebServerFactory类型的Bean、或者存在UndertowServletWebServerFactory类型的Bean。

总结一下：

  1. 有Tomcat依赖，就有TomcatServletWebServerFactory这个Bean
  2. 有Jetty依赖，就有JettyServletWebServerFactory这个Bean
  3. 有Undertow依赖，就有UndertowServletWebServerFactory这个Bean

那么SpringBoot给我们配置的这几个Bean到底有什么用呢？

我们前面说到，TomcatServletWebServerFactory实现了ServletWebServerFactory这个接口，这个接口的定义为：

public interface ServletWebServerFactory {
	WebServer getWebServer(ServletContextInitializer... initializers);
}

public interface WebServer {
	void start() throws WebServerException;
	void stop() throws WebServerException;
	int getPort();
}

我们发现ServletWebServerFactory其实就是用来获得WebServer对象的，而WebServer拥有启动、停止、获取端口等方法，那么很自然，我们就发现WebServer其实指的就是Tomcat、Jetty、Undertow，而TomcatServletWebServerFactory就是用来生成Tomcat所对应的WebServer对象，具体一点就是TomcatWebServer对象，并且在生成TomcatWebServer对象时会把Tomcat给启动起来，在源码中，调用TomcatServletWebServerFactory对象的getWebServer()方法时就会启动Tomcat。

我们再来看TomcatServletWebServerFactory这个Bean的定义：

@Bean
TomcatServletWebServerFactory tomcatServletWebServerFactory(
	ObjectProvider<TomcatConnectorCustomizer> connectorCustomizers,
	ObjectProvider<TomcatContextCustomizer> contextCustomizers,
	ObjectProvider<TomcatProtocolHandlerCustomizer<?>> protocolHandlerCustomizers) {
	TomcatServletWebServerFactory factory = new TomcatServletWebServerFactory();
	
	// orderedStream()调用时会去Spring容器中找到TomcatConnectorCustomizer类型的Bean，默认是没有的，程序员可以自己定义
	factory.getTomcatConnectorCustomizers()
		.addAll(connectorCustomizers.orderedStream().collect(Collectors.toList()));
	factory.getTomcatContextCustomizers()
		.addAll(contextCustomizers.orderedStream().collect(Collectors.toList()));
	factory.getTomcatProtocolHandlerCustomizers()
		.addAll(protocolHandlerCustomizers.orderedStream().collect(Collectors.toList()));
	return factory;
}

要构造这个Bean，Spring会从Spring容器中获取到TomcatConnectorCustomizer、TomcatContextCustomizer、TomcatProtocolHandlerCustomizer这三个类型的Bean，然后把它们添加到TomcatServletWebServerFactory对象中去，很明显这三种Bean是用来配置Tomcat的，比如：

  1. TomcatConnectorCustomizer：是用来配置Tomcat中的Connector组件的
  2. TomcatContextCustomizer：是用来配置Tomcat中的Context组件的
  3. TomcatProtocolHandlerCustomizer：是用来配置Tomcat中的ProtocolHandler组件的

也就是我们可以通过定义TomcatConnectorCustomizer类型的Bean，来对Tomcat进行配置，比如：

@SpringBootApplication
public class MyApplication {

	@Bean
	public TomcatConnectorCustomizer tomcatConnectorCustomizer(){
		return new TomcatConnectorCustomizer() {
			@Override
			public void customize(Connector connector) {
				connector.setPort(8888);
			}
		};
	}

	public static void main(String[] args) {
		SpringApplication.run(MyApplication.class);
	}

}

这样Tomcat就会绑定8888这个端口。

有了TomcatServletWebServerFactory这个Bean之后，在SpringBoot的启动过程中，会执行ServletWebServerApplicationContext的onRefresh()方法，而这个方法会调用createWebServer()方法，而这个方法中最为重要的两行代码为：

ServletWebServerFactory factory = getWebServerFactory();
this.webServer = factory.getWebServer(getSelfInitializer());

很明显，getWebServerFactory()负责获取具体的ServletWebServerFactory对象，要么是TomcatServletWebServerFactory对象，要么是JettyServletWebServerFactory对象，要么是UndertowServletWebServerFactory对象，注意只能获取到一个，然后调用该对象的getWebServer方法，启动对应的Tomcat、或者Jetty、或者Undertow。

getWebServerFactory方法中的逻辑比较简单，获取Spring容器中的ServletWebServerFactory类型的Bean对象，如果没有获取到则抛异常，如果找到多个也抛异常，也就是在Spring容器中只能有一个ServletWebServerFactory类型的Bean对象。

拿到TomcatServletWebServerFactory对象后，就调用它的getWebServer方法，而在这个方法中就会生成一个Tomcat对象，并且利用前面的TomcatConnectorCustomizer等等会Tomcat对象进行配置，最后启动Tomcat。

这样在启动应用时就完成了Tomcat的启动，到此我们通过这个案例也看到了具体的Starter机制、自动配置的具体使用。

自动配置类ServletWebServerFactoryAutoConfiguration中，还会定义一个ServletWebServerFactoryCustomizer类型的Bean，定义为：

@Bean
public ServletWebServerFactoryCustomizer servletWebServerFactoryCustomizer(ServerProperties serverProperties,
																		   ObjectProvider<WebListenerRegistrar> webListenerRegistrars,
																		   ObjectProvider<CookieSameSiteSupplier> cookieSameSiteSuppliers) {
	return new ServletWebServerFactoryCustomizer(serverProperties,
												 webListenerRegistrars.orderedStream().collect(Collectors.toList()),
												 cookieSameSiteSuppliers.orderedStream().collect(Collectors.toList()));
}

这个Bean会接收一个ServerProperties的Bean，ServerProperties的Bean对应的就是properties文件中前缀为server的配置，我们可以利用ServerProperties对象的getPort方法获取到我们所配置的server.port的值。

而ServletWebServerFactoryCustomizer是针对一个ServletWebServerFactory的自定义器，也就是用来配置TomcatServletWebServerFactory这个Bean的，到时候ServletWebServerFactoryCustomizer就会利用ServerProperties对象来对TomcatServletWebServerFactory对象进行设置。

在ServletWebServerFactoryAutoConfiguration这个自动配置上，除开Import了EmbeddedTomcat、EmbeddedJetty、EmbeddedUndertow这三个配置类，还Import了一个ServletWebServerFactoryAutoConfiguration.BeanPostProcessorsRegistrar.class，这个BeanPostProcessorsRegistrar会向Spring容器中注册一个WebServerFactoryCustomizerBeanPostProcessor类型的Bean。

WebServerFactoryCustomizerBeanPostProcessor是一个BeanPosrtProcessor，它专门用来处理类型为WebServerFactory的Bean对象，而我们的TomcatServletWebServerFactory、JettyServletWebServerFactory、UndertowServletWebServerFactory也都实现了这个接口，所以不管当前项目依赖的情况，只要在Spring在创建比如TomcatServletWebServerFactory这个Bean时，WebServerFactoryCustomizerBeanPostProcessor就会对它进行处理，处理的逻辑为：

  1. 从Spring容器中拿到WebServerFactoryCustomizer类型的Bean，也就是前面说的ServletWebServerFactoryCustomizer对象
  2. 然后调用ServletWebServerFactoryCustomizer对象的customize方法，把TomcatServletWebServerFactory对象传入进去
  3. customize方法中就会从ServerProperties对象获取各种配置，然后设置给TomcatServletWebServerFactory对象

比如：

这样当TomcatServletWebServerFactory这个Bean对象创建完成后，它里面的很多属性，比如port，就已经是程序员所配置的值了，后续执行getWebServer方法时，就直接获取自己的属性，比如port属性，设置给Tomcat，然后再利用TomcatConnectorCustomizer等进行处理，最后启动Tomcat。

到此，SpringBoot整合Tomcat的核心原理就分析完了，主要涉及的东西有：

  1. spring-boot-starter-web：会自动引入Tomcat、SpringMVC的依赖
  2. ServletWebServerFactoryAutoConfiguration：自动配置类
  3. ServletWebServerFactoryAutoConfiguration.BeanPostProcessorsRegistrar：用来注册WebServerFactoryCustomizerBeanPostProcessor
  4. ServletWebServerFactoryConfiguration.EmbeddedTomcat：配置TomcatServletWebServerFactory
  5. ServletWebServerFactoryConfiguration.EmbeddedJetty：配置JettyServletWebServerFactory
  6. ServletWebServerFactoryConfiguration.EmbeddedUndertow：配置UndertowServletWebServerFactory
  7. ServletWebServerFactoryCustomizer：用来配置ServletWebServerFactory
  8. WebServerFactoryCustomizerBeanPostProcessor：是一个BeanPostProcessor，利用ServletWebServerFactoryCustomizer来配置ServletWebServerFactory
  9. ServletWebServerApplicationContext中的onRefresh()方法：负责启动Tomcat

Spring Boot AOP自动配置

@Configuration(proxyBeanMethods = false)

// spring.aop.auto=true时开启AOP，或者没有配置spring.aop.auto时默认也是开启
@ConditionalOnProperty(prefix = "spring.aop", name = "auto", havingValue = "true", matchIfMissing = true)
public class AopAutoConfiguration {

	@Configuration(proxyBeanMethods = false)
	@ConditionalOnClass(Advice.class)
	static class AspectJAutoProxyingConfiguration {

		@Configuration(proxyBeanMethods = false)
		// 开启AOP的注解，使用JDK动态代理
		@EnableAspectJAutoProxy(proxyTargetClass = false)
		// spring.aop.proxy-target-class=false时才生效
		@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "false")
		static class JdkDynamicAutoProxyConfiguration {

		}

		
		@Configuration(proxyBeanMethods = false)
		// 开启AOP的注解，使用CGLIB动态代理
		@EnableAspectJAutoProxy(proxyTargetClass = true)
		// spring.aop.proxy-target-class=true时生效，或者没有配置spring.aop.proxy-target-class时默认也生效
		@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true",
				matchIfMissing = true)
		static class CglibAutoProxyConfiguration {

		}

	}

	@Configuration(proxyBeanMethods = false)
	// 没有aspectj的依赖，但是又要使用cglib动态代理
	@ConditionalOnMissingClass("org.aspectj.weaver.Advice")
	@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true",
			matchIfMissing = true)
	static class ClassProxyingConfiguration {

		@Bean
		static BeanFactoryPostProcessor forceAutoProxyCreatorToUseClassProxying() {
			return (beanFactory) -> {
				if (beanFactory instanceof BeanDefinitionRegistry) {
					BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory;
					// 注册InfrastructureAdvisorAutoProxyCreator从而开启Spring AOP
					// @EnableAspectJAutoProxy会注册AnnotationAwareAspectJAutoProxyCreator，也会开启Spring AOP但是同时有用解析AspectJ注解的功能
					AopConfigUtils.registerAutoProxyCreatorIfNecessary(registry);
					AopConfigUtils.forceAutoProxyCreatorToUseClassProxying(registry);
				}
			};
		}

	}

}

Spring Boot Mybatis自动配置

Mybatis的自动配置类为MybatisAutoConfiguration，该类中配置了一个SqlSessionFactory和AutoConfiguredMapperScannerRegistrar。

SqlSessionFactory这个Bean是Mybatis需要配置的，AutoConfiguredMapperScannerRegistrar会注册并配置一个MapperScannerConfigurer。

public static class AutoConfiguredMapperScannerRegistrar
      implements BeanFactoryAware, EnvironmentAware, ImportBeanDefinitionRegistrar {

    private BeanFactory beanFactory;
    private Environment environment;

    @Override
    public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {

      if (!AutoConfigurationPackages.has(this.beanFactory)) {
        logger.debug("Could not determine auto-configuration package, automatic mapper scanning disabled.");
        return;
      }

      logger.debug("Searching for mappers annotated with @Mapper");

	  // 获取AutoConfigurationPackages Bean从而获取SpringBoot的扫描路径
      List<String> packages = AutoConfigurationPackages.get(this.beanFactory);
      if (logger.isDebugEnabled()) {
        packages.forEach(pkg -> logger.debug("Using auto-configuration base package '{}'", pkg));
      }

      BeanDefinitionBuilder builder = BeanDefinitionBuilder.genericBeanDefinition(MapperScannerConfigurer.class);
      builder.addPropertyValue("processPropertyPlaceHolders", true);

	  // 限制了接口上得加Mapper注解
      builder.addPropertyValue("annotationClass", Mapper.class);
      builder.addPropertyValue("basePackage", StringUtils.collectionToCommaDelimitedString(packages));
      BeanWrapper beanWrapper = new BeanWrapperImpl(MapperScannerConfigurer.class);
      Set<String> propertyNames = Stream.of(beanWrapper.getPropertyDescriptors()).map(PropertyDescriptor::getName)
          .collect(Collectors.toSet());
      if (propertyNames.contains("lazyInitialization")) {
        // Need to mybatis-spring 2.0.2+
        builder.addPropertyValue("lazyInitialization", "${mybatis.lazy-initialization:false}");
      }
      if (propertyNames.contains("defaultScope")) {
        // Need to mybatis-spring 2.0.6+
        builder.addPropertyValue("defaultScope", "${mybatis.mapper-default-scope:}");
      }

      // for spring-native
      boolean injectSqlSession = environment.getProperty("mybatis.inject-sql-session-on-mapper-scan", Boolean.class,
          Boolean.TRUE);
      if (injectSqlSession && this.beanFactory instanceof ListableBeanFactory) {
        ListableBeanFactory listableBeanFactory = (ListableBeanFactory) this.beanFactory;
        Optional<String> sqlSessionTemplateBeanName = Optional
            .ofNullable(getBeanNameForType(SqlSessionTemplate.class, listableBeanFactory));
        Optional<String> sqlSessionFactoryBeanName = Optional
            .ofNullable(getBeanNameForType(SqlSessionFactory.class, listableBeanFactory));
        if (sqlSessionTemplateBeanName.isPresent() || !sqlSessionFactoryBeanName.isPresent()) {
          builder.addPropertyValue("sqlSessionTemplateBeanName",
              sqlSessionTemplateBeanName.orElse("sqlSessionTemplate"));
        } else {
          builder.addPropertyValue("sqlSessionFactoryBeanName", sqlSessionFactoryBeanName.get());
        }
      }
      builder.setRole(BeanDefinition.ROLE_INFRASTRUCTURE);

      registry.registerBeanDefinition(MapperScannerConfigurer.class.getName(), builder.getBeanDefinition());
    }

    @Override
    public void setBeanFactory(BeanFactory beanFactory) {
      this.beanFactory = beanFactory;
    }

    @Override
    public void setEnvironment(Environment environment) {
      this.environment = environment;
    }

    private String getBeanNameForType(Class<?> type, ListableBeanFactory factory) {
      String[] beanNames = factory.getBeanNamesForType(type);
      return beanNames.length > 0 ? beanNames[0] : null;
    }

  }

Kudo新一
关注
  • 38
    点赞
  • 踩
  • 26
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Spring Boot 自动配置
weixin_61700639的博客
04-09 323
Spring Boot 的巨大优势在于我们可以专注于业务规则，从而避免一些繁琐的开发步骤、样板代码和更复杂的配置，从而改进开发并简化新 Spring 应用程序的引导。 为了开始配置新的 Spring Boot 应用程序，Spring Initializr 创建了一个简单的 POJO 类来配置应用程序的初始化。我们有两种方式来装饰配置。一种是@SpringBootApplication当我们的解决方案中的模块较少时使用注释。 如果我们有一个结构更复杂的解决方案，我们需要将不同的路径或我们模块的基本
SpringBoot自动配置原理
m0_67942533的博客
08-14 7384
SpringBoot自动配置原理
SpringBoot的自动配置
CNDN_Web的博客
05-26 1189
如何理解SpringBoot的自动配置原理
springboot的自动配置
最新发布
2401_83287540的博客
07-24 852
1.通过Condition注解----固定文件的自动配置实现过程:首先定义一个类其次:定义一个类,实现Condition接口,在重写其中的matches方法,判断相关的文件是否存在最后:通过创建配置类,通过Condition注解 @Conditional(value= 实现类类名.class)//@Conditional中的 实现类类名.class的matches方法，返回true则将该类通过@bean注解注入到spring容器中，返回false则不注入到spring容器中，
01.SpringBoot自动配置原理.pdf
04-22
SpringBoot自动配置原理 SpringBoot自动配置原理是指SpringBoot框架中的一种机制，该机制可以自动配置应用程序所需的各种Bean和依赖项，使得开发者无需手动配置繁多的配置文件和pom坐标。下面将详细介绍SpringBoot...
浅谈springboot自动配置原理
08-25
浅谈SpringBoot自动配置原理 SpringBoot自动配置原理是SpringBoot框架的核心机制之一，它使得开发者可以更方便、更快速地构建应用程序。自动配置原理的核心是通过@EnableAutoConfiguration注解开启自动配置功能，...
SpringBoot自动配置解析
07-30
分析springboot如何进行自动配置的,注解是如何工作,以及使用要点.
springboot自动配置流程
m0_51287945的博客
11-17 920
springboot自动配置功能
Spring Boot 的自动配置
qq_43012298的博客
01-23 1479
Spring Boot自动配置的核心是注解和文件的配合。通过条件注解和Condition实现类的条件评估机制，Spring Boot在运行时动态地应用自动配置。自动配置的过程涉及到多个步骤和组件，但它大大简化了Spring应用的配置过程，让开发者可以快速地搭建和运行一个Spring应用。整个自动配置过程是Spring Boot提供的一个强大功能，它通过约定大于配置的方式，减少了手动配置的复杂性和可能出现的错误，实现了快速、灵活且可靠的应用程序开发。
Spring Boot自动配置
quanzhan_King的博客
04-24 1924
Spring boot 特性：1、能够快速创建基于Spring的应用程序； 2、能够直接使用java main方法启动内嵌的Tomcat，Jetty服务器运行Spring boot程序，不需要部署war包文件； 3、提供约定的starter POM来简化Maven配置，让Maven的配置变得简单； 4、根据项目的Maven依赖配置，Spring boot自动配置Spring、Spring mvc等； 5、提供了程序的健康检查等功能； 6、基本可以完全不使用XML配置文件，采用注解配置。
springboot-自动配置
qq_44895567的博客
06-11 1929
根据条件注解（如 @ConditionalOnClass、@ConditionalOnMissingBean 等），决定是否加载对应的配置类或 Bean。：在主类上添加 @SpringBootApplication 注解，该注解包含 @EnableAutoConfiguration，开启自动配置功能。@ConditionalOnProperty：当指定的配置属性存在并符合预期时，才会实例化相应的 Bean。@ConditionalOnClass：当类路径上存在指定的类时，才会实例化相应的 Bean。
springBoot自动配置
qq_45055165的博客
05-02 446
一 自动配置步骤： 1 编写 Java config @Configuration 2 添加条件 @Conditional 3.定位自动配置 META-INF/spring.factories 二 条件注解大家庭 1.条件注解 @Conditional @Conditional是Spring4新提供的注解，它的作用是按照一定的条件进行判断，满足条件给容器注册bean。 参数是Condition类的集合看看Condition接口 matches就像正则的那个类一样…应该是true注入,false
学记：为spring boot写一个自动配置
anchichun6550的博客
12-17 128
　　spring boot遵循“约定优于配置”的原则，使用annotation对一些常规的配置项做默认配置，减少或不使用xml配置，让你的项目快速运行起来。spring boot的神奇不是借助代码的生成来实现的，而是通过条件注解来实现的。 　　自动配置AutoConfiguration是实现spring boot的重要原理，理解AutoConfiguration的运行原理特别重要，自己...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值