注解驱动和注解配置有什么区别

‘壹’ spring里注解驱动是必须要配的吗

spring里注解驱动是必须要配的。根据公开资料显示得知Spring或Springmvc框架中要使用注解，需要配置注解驱动。

‘贰’ springmvc配置问题，applicationContext中如果不写注解驱动会怎么样，好像没写也能运行项目

springmvc声明式开发，分为xml和注解开发。因此，即使没有使用注解，使用的是xml也是能正常运行项目的。

如果满意，望采纳，谢谢！

‘叁’ springBoot @RequestBody 写在方法上与写在参数上的区别

1. @Controller控制层组件，定义一个springMVC的控制器类，往往需要和@RequestMapping配合使用。2. @RestController相当于@ResponseBody+@Controller合在一起的作用。3. @Service服务层组件，用于标注业务层组件，表示定义一个bean，自动根据bean的类名实例化一个首写字母为小写的bean，也可以指定bean的名称：@Service(“beanName”)。4. @Repository持久层组件，用于标注数据访问组件，即DAO组件。5. @Component把普通pojo实例化到spring容器中，相当于配置文件中的 <bean id="" class=""/>。6. @RequestMapping用于配置控制层的访问URL，可以用在控制器类上和控制器方法上，如果用在控制器类上，则访问类中的方法是要加上类上的路径，例如：@Controller@RequestMapping("/personal/linkInfo")public class LinkInfoController {@RequestMapping(value = "/addLinkInfo")public String addLinkInfo(LinkInfoReq linkInfoReq) {linkInfoService.addLinkInfo(linkInfoReq);return "redirect:/personal/linkInfo/toLinkInfo";}}上述代码的访问路径就是XXX/personal/linkInfo/addLinkInfo。@RequestMapping源代码如下图：a) value：设置访问的URL，数组，可以将多个请求映射到一个方法上去。支持通配符配置代码示例：@RequestMapping(value = {"/page","/page*"})public void getInfo() {}上述代码访问路径可以是：XXX/page，XXX/pageadc等满足value条件的路径。b) method：设置访问的方法，数组，可是设置多个访问方法映射到同一个方法上，默认为GET方法代码示例：@RequestMapping(value = "/page", method = RequestMethod.POST)public void getInfo() {}上述代码 /page路径就只能用POST方法才能请求。method的可选值有GET,HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE。c) params：指定request中必须包含某些参数值是，才让该方法处理。数组。@RequestMapping(value = "/page", params = {"type=1"})public void getInfo() {}上述代码/page路径只有请求参数中包含type且值等于1时才能访问该方法。d) headers：指定request中必须包含某些指定的header值，才能让该方法处理请求。数组。示例代码：@RequestMapping(value = "/page", headers = {" content-type=text/plain " })public void getInfo() {}上述代码/page路径只有headers中content-type=text/plain才能访问该方法。e) consumes：指定处理请求的提交内容类型（Content-Type），例如application/json, text/html。f) proces：指定返回的内容类型，仅当request请求头中的(Accept)类型中包含该指定类型才返回。7. @ResponseBody通常使用在controller方法上，作用是将方法的返回值通过合适的HttpMessageConverter转换成特定格式写入到response的body区域，然后返回给客户端，如果没有使用@RequestBody注解，方法返回值将会封装到ModelAndView并解析返回视图。8. @RequestParam接受的参数来自requestHeader，即请求头，用来接收GET和POST请求参数并将参数赋值到被@RequestParam注解的变量上，同样可以使用requet.getParameter(“name”)获取，默认的参数接受方式，如果controller方法的参数未使用@RequestParam，则默认也是使用@RequestParam接受参数。用来处理Content-Type: 为 application/x-www-form-urlencoded编码的内容。@RequestParam有三个配置参数：a) required：是否必须，默认true，必须。b) defaultValue：默认值，请求的参数为空时使用默认值。c) value：请求的参数名。9. @RequestBody接受的参数来自requestBody，即请求体，一般用于处理非 Content-Type: application/x-www-form-urlencoded编码格式的数据，比如：application/json、application/xml等类型的数据。10. @Autowired它可以对类成员变量，方法及构造函数进行标注，完成自动装配工作，可以消除set，get方法。11. @Resource其作用和@Autowired相似。不同点：@Resource是java自己的注解，@Resource有两个属性重要属性，分是name和type；Spring将@Resource注解的name属性解析为bean的名字，而type属性则解析为bean的类型。所以如果使用name属性，则使用byName的自动注入策略，而使用type属性时则使用byType自动注入策略。如果既不指定name也不指定type属性，这时将通过反射机制使用byName自动注入策略。@Autowired是spring的注解，是spring2.5版本引入的，@Autowired只根据type进行注入，不会去匹配name。如果涉及到type无法辨别注入对象时，那需要依赖@Qualifier注解一起来修饰。@Resource装配顺序a) 如果同时指定了name和type，则从Spring上下文中找到唯一匹配的bean进行装配，找不到则抛出异常b) 如果指定了name，则从上下文中查找名称（id）匹配的bean进行装配，找不到则抛出异常c) 如果指定了type，则从上下文中找到类型匹配的唯一bean进行装配，找不到或者找到多个，都会抛出异常d) 如果既没有指定name，又没有指定type，则自动按照byName方式进行装配；如果没有匹配，则回退为一个原始类型进行匹配，如果匹配则自动装配；推荐使用@Resource，不用谢set方法，并且这个注解属于java自己的，减少了与spring的耦合度。12. @Value该注解有两种使用方式：a) @Value(“${}”)这种使用方式注入的是配置文件里的参数这样配置文件中的com.title就能配置到LinkInfoController的title属性中b) @Value(“#{}”)该方式表示SpEl表达式通常用来获取bean的属性，或者调用bean的某个方法。这样就可以把User对象的name配置到LinkInfoController的name属性中。13. @Transactional用于配置spring事务管理。属性信息如下：事物的传播行为如下：14. @SpringBootApplication该注解其实是一个组合注解，源码如下图：比较重要的注解有三个：a) @SpringBootConfiguration从源代码可以看到@SpringBootConfiguration继承自@Configuration，这两个注解的功能也是一样的。b) @EnableAutoConfiguration此注释自动载入应用程序所需的所有Bean。c) @ComponentScan该注解会扫描指定路径下的的类，并将其加入到IoC容器中。在springboot中，@ComponentScan默认扫描@SpringBootApplication所在类的同级目录以及它的子目录。15. @Configuration从Spring3.0，@Configuration用于定义配置类，可替换xml配置文件，被注解的类内部包含有一个或多个被@Bean注解的方法，这些方法将会被或类进行扫描，并用于构建bean定义，初始化Spring容器。16. @Bean该注解主要用在@Configuration注解的类里，也可以用在@Component注解的类里。添加的bean的id为方法名。相当于配置文件里的<bean></bean>。@Configurationpublic class RedisConfig extends CachingConfigurerSupport{@Beanpublic CacheManager cacheManager(RedisConnectionFactory connectionFactory) {RedisCacheManager redisCacheManager = RedisCacheManager.create(connectionFactory);return redisCacheManager;}}如上代码就相当于在xml文件里配置：<beans><bean id=" cacheManager " class=" com.mypage.config. RedisCacheManager "/></beans>17. @MapperScan指定要变成实现类的接口所在的包，然后包下面的所有接口在编译之后都会生成相应的实现类添加位置：是在Springboot启动类上面添加：18. @EnableCaching该注解是spring framework中的注解驱动的缓存管理功能。自spring版本3.1起加入了该注解。如果你使用了这个注解，那么你就不需要在XML文件中配置cache manager了。@Configuration@EnableCachingpublic class RedisConfig extends CachingConfigurerSupport{/*** 采用RedisCacheManager作为缓存管理器* @param connectionFactory* @return*/@Beanpublic CacheManager cacheManager(RedisConnectionFactory connectionFactory) {RedisCacheManager redisCacheManager = RedisCacheManager.create(connectionFactory);return redisCacheManager;}}19. @EnableRedisHttpSession用来设置springboot使用redis存储session，该注解会创建一个名字叫springSessionRepositoryFilter的Spring Bean，其实就是一个Filter，这个Filter负责用Spring Session来替换原先的默认HttpSession实现。示例代码如下：@Configuration@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 60*30)public class HttpSessionConfig {}其中属性maxInactiveIntervalInSeconds是设置session的有效时间，单位毫秒，默认1800ms。但其实这样还是不够的，还要在配置文件中设置redis存储session:spring.session.store-type=redis这样就可以了。

‘肆’ spring2.0 和 spring2.5的区别

Spring经历了两次大修订，第一次是2006年10月的Spring2.0，另一次是2007年11月的Spring2.5。
简介：
1． JDK版本： JDK至少要1.4.2以上，如果仍然打算使用1.3的话就请用2.0.6/2.0.7版本吧。

(2) Spring对Java EE的支持
Spring框架继续保持对Java EE1.3及以后版本的兼容，完全支持Java EE 5。
(3) Spring对服务器(应用服务器和Web服务器)的支持
WebLogic：8.1、9.0、9.2、10
WebSphere：5.1、6.0、6.1
OC4J(Oracle)：10.1.3、11
JBoss：3.2、4.0、4.2
Tomcat：4.1、5.0、5.5、6.0
Jetty：4.2、5.1、6.1
Resin：2.1、3.0、3.1
GlassFish：v1、v2

控制反转(IoC)容器：
(1) 新的bean作用域
Spring2.0
IoC容器中只支持singleton和prototype两个不同的bean作用域，而在Spring2.5中则还支持request、session、global
session三个在web环境下使用的bean作用域，且提供了hooks，可以让用户创建自己的作用域。
(2) XML配置更简单
Spring2.5对Spring 2.0的DTD进行了更新，使用时：<!DOCTYPE beans
PUBLIC "-//SPRING//DTD BEAN 2.0//EN"

"http://www.springframework.org/dtd/spring-beans-2.0.dtd">
spring-beans-2.0.dtd可在发布包下的dist/resources下找到。
(3) Annotation(注解)驱动配置
Spring2.5引入了完整的Annotation集合如：@Resource、@Autowired等

面向切面编程(AOP)：
(1) 更简单的AOP XML配置
支持定义从JAVA对象中发展中来的切面
(2) 对@AspectJ的支持
加入了对bean(...)pointcut 元素的支持，在 spring定义的bean命名中对指定的命名进行匹配
(3) 对AspectJ load-time weaving的支持

中间层：
(1) XML声明式事务配置更简单
以前版本的事务配置方式仍然支持，Spring2.5支持装载时织入和注解驱动的事务管理，这是通过context:load-time-weaver
和tx:annotation-driven mode="aspectj"的联合使用进行的。
(2) 对Websphere 事务管理的完整支持
自动探测底层的JTA 事务平台，可以使用Spring 2.5的新 tx:jta-transaction-manager
配置元素。它会自动探测BEA WebLogic和IBM
WebSphere,注册正确的PlatformTransactionManager。
(3) JPA
Spring 2.5对OpenJPA的支持升级到了OpenJPA 1.0，支持savepoint这样的高级特性
(4) 异步的JMS
在Spring 2.5中，
JCA风格的异步消息监听器设置也通过GenericMessageEndpointManager工具得到了支持。这是对标准JMS监听器工具的补充，允许对ActionMQ和JORAM这些消息broker进行更深入的集成。Spring
2.5 还引入了一个XML
namespace来简化JMS配置，可以对大量监听器进行简明配置。这一命名空间支持标准的JMS监听器和JCA
setup风格，在配置时只有很小的改变。
(5) JDBC
引入了新类，Spring 2.5显着的扩充了SimpleJdbcTemplate的功能，引入了SimpleJdbcCall
和SimpleJdbcInsert操作对象。

移植到Spring2.5：

从Spring2.0.X升级到Spring2.5只需要把Spring2.5的jar复制到您工程目录相应的配置。

改动处：可以参考发布包下的changelog.txt文件
在Spring2.5中，Spring Web
MVC不再在spring.jar里，Spring
MVC发布在lib/moles下，包是：spring-webmvc.jar和spring-webmvc-portlet.jar。

对struts1.x的支持独立成spring-webmvc-struts.jar。
Spring2.0的'spring-jmx.jar'和
'spring-remoting.jar'已经被转移到 Spring 2.5的'spring-context.jar'。
Spring 2.0的
'spring-support.jar' 被改名为 'spring-context-support.jar'。
Spring 2.0的'spring-jdo.jar', 'spring-jpa.jar',
'spring-hibernate3.jar', 'spring-toplink.jar' 和 'spring-ibatis.jar'
被合并到Spring 2.5大粒度的'spring-orm.jar'中。
Spring 2.5的 'spring-test.jar' 取代了'spring-mock.jar'。
Spring 2.5的 'spring-tx.jar' 取代了 'spring-.jar' 和'spring-jca.jar'
文件。
Spring主代码中的Apache OJB支持被完全删除了。
iBATIS SQL Maps 1.3支持被完全去除了。
Spring 2.5中，对 Hibernate 2.1 和 Hibernate 3.0 的支持已经去除。
Spring 2.5中，对JDO 1.0 的支持被去除。

2.5的新特性

Spring2.5rc1发布了，一直想知道它葫芦里卖什么药，以下是文档里的change.log

1． JDK版本： JDK至少要1.4.2以上，如果仍然打算使用1.3的话就请用2.0.6/2.0.7版本吧。
2． Jar包：SpringMVC 不再使用spring.jar 这个庞大的包了。 Spring-webmvc.jar,
spring-webmvc-portlet.jar 可以在 lib/moles 目录下找到，而且对于Struts1.*
的支持的包也应该改成 spring-webmvc-struts.jar了。
3． XML配置：推荐使用XML
metadata格式，不过先前的DTD仍然支持。需要注意的一点是，Spring1.2的DTD继续使用“singleton”属性，但是新的Spring2.0
DTD不允许使用“singleton”属性了，改成“scope”属性来描述bean的生命周期。
4． 废弃的类与方法：有些在先前版本标注过“@deprecated”的类与方法已经完全被废弃了。
比如：
ResultReader : 被 RowMapper 接口取代。
BeanFactoryBootstrap : 考虑使用 BeanFactoryLocator
或自定义的bootstrap类来代替。
5． Apache OJB：注意Spring源代码中已经完全把这个去掉了，但与之整合的类仍然可以在Spring Moles
project找到。https://springmoles.dev.java.net/
6． iBATIS：注意Spring已经不再支持iBATIS 的1.3版本了，
如果想继续的话，请升级到2.3以上吧。
7． Hibernate：注意Spring已经不再支持Hibernate
3.1之前的版本了，也就是说2.1，3.0的版本也无法使用了。如果仍然要用的话，推荐使用Spring的2.0.6/2.0.7版本。
8．
JDO：注意Spring已经不支持JDO1.0了。同样，你可以升级到2.0以上版本，或者使用Spring的2.0.6/2.0.7版本。
9． UrlFilenameViewControlle
r ：这个东东我也没有接触过，这里，我就简单翻译一下吧。
“考虑到嵌套路径的请求，视图名称现在决定叫UrlFilenameViewControlle
r了，这是一个突破性的改变，并且意味着如果你从Spring1.*
升级到Spring2.0 你可以使用该类从而减少Spring Web MVC的配置工作。”

‘伍’ SpringBoot核心原理：自动配置、事件驱动、Condition

SpringBoot是Spring的包装，通过自动配置使得SpringBoot可以做到开箱即用，上手成本非常低，但是学习其实现原理的成本大大增加，需要先了解熟悉Spring原理。

如果还不清楚Spring原理的，可以先查看博主之前的文章，本篇主要分析SpringBoot的启动、自动配置、Condition、事件驱动原理。

SpringBoot启动非常简单，因其内置了Tomcat，所以只需要通过下面几种方式启动即可：

可以看到第一种是最简单的，也是最常用的方式，需要注意类上面需要标注 @SpringBootApplication 注解，这是自动配置的核心实现，稍后分析，先来看看SpringBoot启动做了些什么？

在往下之前，不妨先猜测一下，run方法中需要做什么？对比Spring源码，我们知道，Spring的启动都会创建一个 ApplicationContext 的应用上下文对象，并调用其refresh方法启动容器，SpringBoot只是Spring的一层壳，肯定也避免不了这样的操作。

另一方面，以前通过Spring搭建的项目，都需要打成War包发布到Tomcat才行，而现在SpringBoot已经内置了Tomcat，只需要打成Jar包启动即可，所以在run方法中肯定也会创建对应的Tomcat对象并启动。以上只是我们的猜想，下面就来验证，进入run方法：

SpringBoot的启动流程就是这个方法，先看 getRunListeners 方法，这个方法就是去拿到所有的 SpringApplicationRunListener 实现类，这些类是用于SpringBoot事件发布的，关于事件驱动稍后分析，这里主要看这个方法的实现原理：

一步步追踪下去可以看到最终就是通过SPI机制根据接口类型从 META-INF/spring.factories 文件中加载对应的实现类并实例化，SpringBoot的自动配置也是这样实现的。

为什么要这样做呢？通过注解扫描不可以么？当然不行，这些类都在第三方jar包中，注解扫描实现是很麻烦的，当然你也可以通过 @Import 注解导入，但是这种方式不适合扩展类特别多的情况，所以这里采用SPI的优点就显而易见了。

回到run方法中，可以看到调用了 createApplicationContext 方法，见名知意，这个就是去创建应用上下文对象：

注意这里通过反射实例化了一个新的没见过的上下文对象 ，这个是SpringBoot扩展的，看看其构造方法：

如果你有看过Spring注解驱动的实现原理，这两个对象肯定不会陌生，一个实支持注解解析的，另外一个是扫描包用的。

上下文创建好了，下一步自然就是调用refresh方法启动容器：

这里首先会调用到其父类中 ：

可以看到是直接委托给了父类：

这个方法不会陌生吧，之前已经分析过了，这里不再赘述，至此SpringBoot的容器就启动了，但是Tomcat启动是在哪里呢？run方法中也没有看到。

实际上Tomcat的启动也是在refresh流程中，这个方法其中一步是调用了onRefresh方法，在Spring中这是一个没有实现的模板方法，而SpringBoot就通过这个方法完成了Tomcat的启动：

这里首先拿到 TomcatServletWebServerFactory 对象，通过该对象再去创建和启动Tomcat：

上面的每一步都可以对比Tomcat的配置文件，需要注意默认只支持了http协议：

如果想要扩展的话则可以对 additionalTomcatConnectors 属性设置值，需要注意这个属性没有对应的setter方法，只有 addAdditionalTomcatConnectors 方法，也就是说我们只能通过实现 BeanFactoryPostProcessor 接口的 postProcessBeanFactory 方法，而不能通过 的 方法，因为前者可以通过传入的BeanFactory对象提前获取到 TomcatServletWebServerFactory 对象调用 addAdditionalTomcatConnectors 即可；而后者只能拿到BeanDefinition对象，该对象只能通过setter方法设置值。

这段代码会在控制台打印所有的事件名称，按照顺序如下：

以上是正常启动关闭，如果发生异常还有发布 ApplicationFailedEvent 事件。事件的发布遍布在整个容器的启动关闭周期中，事件发布对象刚刚我们也看到了是通过SPI加载的 SpringApplicationRunListener 实现类 EventPublishingRunListener ，同样事件监听器也是在 spring.factories 文件中配置的，默认实现了以下监听器：

可以看到有用于文件编码的（ ），有加载日志框架的（ LoggingApplicationListener ），还有加载配置的（ ConfigFileApplicationListener ）等等一系列监听器，SpringBoot也就是通过这系列监听器将必要的配置和组件加载到容器中来，这里不再详细分析，感兴趣的读者可以通过其实现的 onApplicationEvent 方法看到每个监听器究竟是监听的哪一个事件，当然事件发布和监听我们自己也是可以扩展的。

SpringBoot最核心的还是自动配置，为什么它能做到开箱即用，不再需要我们手动使用 @EnableXXX 等注解来开启？这一切的答案就在 @SpringBootApplication 注解中：

这里重要的注解有三个： @SpringBootConfiguration 、 @EnableAutoConfiguration 、 @ComponentScan 。 @ComponentScan 就不用再说了， @SpringBootConfiguration 等同于 @Configuration ，而 @EnableAutoConfiguration 就是开启自动配置：

@AutoConfigurationPackage 注解的作用就是将该注解所标记类所在的包作为自动配置的包，简单看看就行，主要看 ，这个就是实现自动配置的核心类，注意这个类是实现的 DeferredImportSelector 接口。

在这个类中有一个 selectImports 方法。这个方法在我之前的文章这一次搞懂Spring事务注解的解析也有分析过，只是实现类不同，它同样会被 类调用，先来看这个方法做了些什么：

追踪源码最终可以看到也是从 META-INF/spring.factories 文件中拿到所有 EnableAutoConfiguration 对应的值（在 spring-boot-autoconfigure 中）并通过反射实例化，过滤后包装成 AutoConfigurationEntry 对象返回。

看到这里你应该会觉得自动配置的实现就是通过这个 selectImports 方法，但实际上这个方法通常并不会被调用到，而是会调用该类的内部类 AutoConfigurationGroup 的process和selectImports方法，前者同样是通过 getAutoConfigurationEntry 拿到所有的自动配置类，而后者这是过滤排序并包装后返回。

下面就来分析 是怎么调用到这里的，直接进入 processConfigBeanDefinitions 方法：

前面一大段主要是拿到合格的 Configuration 配置类，主要逻辑是在 ConfigurationClassParser.parse 方法中，该方法完成了对 @Component 、 @Bean 、 @Import 、 @ComponentScans 等注解的解析，这里主要看对 @Import 的解析，其它的读者可自行分析。一步步追踪，最终会进入到 processConfigurationClass 方法：

这里需要注意 this.conditionEvaluator.shouldSkip 方法的调用，这个方法就是进行Bean加载过滤的，即根据 @Condition 注解的匹配值判断是否加载该Bean，具体实现稍后分析，继续跟踪主流程 doProcessConfigurationClass ：

这里就是完成对一系列注解的支撑，我省略掉了，主要看 processImports 方法，这个方法就是处理 @Import 注解的：

刚刚我提醒过 是实现 DeferredImportSelector 接口的，如果不是该接口的实现类则是直接调用 selectImports 方法，反之则是调用 DeferredImportSelectorHandler.handle 方法：

首先创建了一个 DeferredImportSelectorHolder 对象，如果是第一次执行则是添加到 deferredImportSelectors 属性中，等到 ConfigurationClassParser.parse 的最后调用process方法：

反之则是直接执行，首先通过register拿到 AutoConfigurationGroup 对象：

然后在 processGroupImports 方法中进行真正的处理：

在 getImports 方法中就完成了对process和 selectImports 方法的调用，拿到自动配置类后再递归调用调用 processImports 方法完成对自动配置类的加载。至此，自动配置的加载过程就分析完了，下面是时序图：

在自动配置类中有很多Condition相关的注解，以AOP为例：

这里就能看到 @ConditionalOnProperty 、 @ConditionalOnClass 、 @ConditionalOnMissingClass ，另外还有 @ConditionalOnBean 、 @ConditionalOnMissingBean 等等很多条件匹配注解。

这些注解表示条件匹配才会加载该Bean，以 @ConditionalOnProperty 为例，表明配置文件中符合条件才会加载对应的Bean，prefix表示在配置文件中的前缀，name表示配置的名称， havingValue 表示配置为该值时才匹配， matchIfMissing 则是表示没有该配置是否默认加载对应的Bean。其它注解可类比理解记忆，下面主要来分析该注解的实现原理。

这里注解点进去看会发现每个注解上都标注了 @Conditional 注解，并且value值都对应一个类，比如 OnBeanCondition ，而这些类都实现了 Condition 接口，看看其继承体系：

上面只展示了几个实现类，但实际上Condition的实现类是非常多的，我们还可以自己实现该接口来扩展 @Condition 注解。Condition接口中有一个matches方法，这个方法返回true则表示匹配。该方法在 ConfigurationClassParser 中多处都有调用，也就是刚刚我提醒过的shouldSkip方法，具体实现是在 ConditionEvaluator 类中：

再来看看matches的实现，但 OnBeanCondition 类中没有实现该方法，而是在其父类 SpringBootCondition 中：

getMatchOutcome 方法也是一个模板方法，具体的匹配逻辑就在这个方法中实现，该方法返回的 ConditionOutcome 对象就包含了是否匹配和日志消息两个字段。进入到 OnBeanCondition 类中：

可以看到该类支持了 @ConditionalOnBean 、 @ConditionalOnSingleCandidate 、 @ConditionalOnMissingBean 注解，主要的匹配逻辑在 getMatchingBeans 方法中：

这里逻辑看起来比较复杂，但实际上就做了两件事，首先通过 getNamesOfBeansIgnoredByType 方法调用 beanFactory.getBeanNamesForType 拿到容器中对应的Bean实例，然后根据返回的结果判断哪些Bean存在，哪些Bean不存在（Condition注解中是可以配置多个值的）并返回MatchResult对象，而MatchResult中只要有一个Bean没有匹配上就返回false，也就决定了当前Bean是否需要实例化。

本篇分析了SpringBoot核心原理的实现，通过本篇相信读者也将能更加熟练地使用和扩展SpringBoot。

另外还有一些常用的组件我没有展开分析，如事务、MVC、监听器的自动配置，这些我们有了Spring源码基础的话下来看一下就明白了，这里就不赘述了。

最后读者可以思考一下我们应该如何自定义starter启动器，相信看完本篇应该难不倒你。

‘陆’ spring常用注解作用与常用接口与后置处理器

从spring2.5之后，spring注解驱动开发慢慢取代了Spring的xml配置文件的作用，而且目前流行的SpringBoot开发也是基于spring注解驱动做扩展的，所以想要理解好SpringBoot，就必须掌握一些spring的注解驱动。

以前xml的做法是

现在使用spring注解的做法是

java8之后ComponentScan注册加了@Repeatable(ComponentScans.class)，可以直接在配置类上标注多个@Componentscan，在java8之前想配置多个@Componentscan扫描，需要用@ComponentScans

给容器注册组件(bean)的几种方式
1.包扫描+组件标注注解(@Service、@Controller、@Repository、@Componet)，这种方式用于导入自己写的类
2.@Bean方式导入，常用入导入第三方包里面的类 默认bean id为导入执行的方法名
3.@Import方式导入(有三种用法)，默认的bean id为全类名
4.通过FactoryBean(工厂bean)

-bean创建->初始化->销毁

applicationContextAeare和EmbeddedValueResolverAeare都是通过后置处理器来实现的

BeanFactoryPostProcessor是在bean定义信息加载完成后调用
是在bean定义信息将要加载时调用
先执行的实现类再执行BeanFactoryPostProcessor的实现类

创建bean的源码位置
org.springframework.context.support.AbstractApplicationContext#
->org.springframework.beans.factory.BeanFactory#getBean(java.lang.String, java.lang.Class<T>)
-->org.springframework.beans.factory.support.AbstractBeanFactory#createBean
--->org.springframework.beans.factory.support.#doCreateBean
执行bean对象的实例化
->org.springframework.beans.factory.support.AbstractBeanFactory#createBean
给bean的属性赋值
org.springframework.beans.factory.support.#populateBean

initializeBean方法主要做了三个操作1.循环执行后置处理器的的前置方法()、2.再执行初始化方法(invokeInitMethods)，3.再执行后置处理器的的后置方法()
org.springframework.beans.factory.support.#initializeBean(java.lang.String, java.lang.Object, org.springframework.beans.factory.support.RootBeanDefinition)

‘柒’ mybatis和ibatis的区别

1、基本信息不同

mybatis：MyBatis 是一款优秀的持久层框架，它支持定制化 SQL、存储过程以及高级映射。MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。

MyBatis 可以使用简单的 XML 或注解来配置和映射原生信息，将接口和 Java 的 POJOs(Plain Ordinary Java Object,普通的 Java对象)映射成数据库中的记录。

ibatis：iBATIS提供的持久层框架包括SQL Maps和Data Access Objects（DAO），同时还提供一个利用这个框架开发的JPetStore实例。相对Hibernate和ApacheOJB等“一站式”ORM解决方案而言，ibatis 是一种“半自动化”的ORM实现。

iBATIS 目前提供了三种语言实现的版本，包括：Java、.NET以及Ruby。

2、开发时间不同

mybatis：MyBatis 本是apache的一个开源项目iBatis, 2010年这个项目由apache software foundation 迁移到了google code，并且改名为MyBatis 。2013年11月迁移到Github。

ibatis：iBATIS一词来源于“internet”和“abatis”的组合，是一个由Clinton Begin在2001年发起的开放源代码项目。

3、配置方法不同

mybatis简化了编码的过程，不需要去写的实现类，直接写一个的接口，再写一个xml配置文件，整个mybatis就配置好了，也就是数据库就连接好了，然后在service里面直接调用就可以了，但是ibatis则不可以，必须要写的实现类。mybatis是ibatis的升级版本。