spring常用注解
一、组件注解
1、 @Component(“xxx”)
指定某个类是容器的bean， @Component(value="xx") 相当于 ，其中 value 可以不写。
用于标注类为spring容器bean的注解有四个， 主要用于区别不同的组件类，提高代码的可读性：
a、 @Component, 用于标注一个普通的bean
b、 @Controller 用于标注一个控制器类（控制层 controller）
c、 @Service 用于标注业务逻辑类（业务逻辑层 service）
d、 @Repository 用于标注DAO数据访问类 （数据访问层 dao）
对于上面四种注解的解析可能是相同的，尽量使用不同的注解提高代码可读性。
注解用于修饰类，当不写value属性值时，默认值为类名首字母小写。
2、 @Scope(“prototype”)
该注解和 @Component 这一类注解联合使用，用于标记该类的作用域，默认 singleton 。
也可以和 @Bean 一起使用，此时 @Scope 修饰一个方法。关于@Bean稍后有说明
3、 @Lazy（true）
指定bean是否延时初始化，相当于 ，默认false。@Lazy可以和@Component这一类注解联合使用修饰类，也可以和@Bean一起使用修饰方法
注 ：此处初始化不是指不执行 init-method ，而是不创建bean实例和依赖注入。只有当该bean（被@Lazy修饰的类或方法）被其他bean引用（可以是自动注入的方式）或者执行getBean方法获取，才会真正的创建该bean实例，其实这也是BeanFactory的执行方式。
4、 @DepondsOn({“aa”，“bb”})
该注解也是配合 @Component 这类注解使用，用于强制初始化其他bean
上面的代码指定，初始化bean “userAction"之前需要先初始化“aa”和“bb”两个bean,但是使用了@Lazy(true)所以spring容器初始化时不会初始化"userAction” bean。
5、 @PostConstructor和@PreDestroy
@PostConstructor 和 @PreDestroy 这两个注解是j2ee规范下的注解。这两个注解用于修饰方法，spring用这两个注解管理容器中spring生命周期行为。
a、 @PostConstructor 从名字可以看出构造器之后调用,相当于 。就是在依赖注入之后执行
b、 @PreDestroy 容器销毁之前bean调用的方法，相当于
6、 @Resource（name=“xx”）
@Resource 可以修饰成员变量也可以修饰set方法。当修饰成员变量时可以不写set方法，此时spring会直接使用j2ee规范的Field注入。
@Resource有两个比较重要的属性，name和type
a、 如果指定了name和type，则从Spring容器中找到唯一匹配的bean进行装配，找不到则抛出异常;
b、 如果指定了name，则从spring容器查找名称（id）匹配的bean进行装配，找不到则抛出异常;
c、 如果指定了type，则从spring容器中找到类型匹配的唯一bean进行装配，找不到或者找到多个，都会抛出异常;
d、 如果既没有指定name，又没有指定type，则自动按照byName方式进行装配
如果没有写name属性值时
a、 修饰成员变量，此时name为成员变量名称
b、 修饰set方法，此时name 为set方法的去掉set后首字母小写得到的字符串
7、 @Autowired（required=false）
@Autowired可以修饰构造器，成员变量，set方法，普通方法。@Autowired默认使用byType方式自动装配。required标记该类型的bean是否是必须的，默认为必须存在（true）。
可以配合 @Qualifier(value="xx") ,实现按beanName注入：
a、 required=true(默认），为true时，从spring容器查找和指定类型匹配的bean，匹配不到或匹配多个则抛出异常
b、 使用 @Qualifier（"xx"） ,则会从spring容器匹配类型和 id 一致的bean，匹配不到则抛出异常
@Autowired会根据修饰的成员选取不同的类型：
a、 修饰成员变量。该类型为成员变量类型
b、 修饰方法，构造器。注入类型为参数的数据类型，当然可以有多个参数
8、demo
业务逻辑层：
数据访问层：
测试类：
输出结果：
可以看到虽然UserDao 使用@Lazy，但是还是在spring容器初始化的时候还是创建了UserDao实例。原因很简单，因为在UserService中需要注入UserDao，所以在此时创建的UserDao实例也属于延时初始化。
在上面我们还使用了两个接口InitializingBean 和DisposableBean，这两个接口用于管理 singleton 作用域的bean的生命周期，类似init-method和destroy-method。不同之处就是调用的循序不一致：
a、 初始化调用顺序 ：@PostConstructor InitializingBean init-method 用于指定bean依赖注入后的行为
b、 销毁调用顺序 @PreDestroy DisposableBean destroy-method 用于定制bean销毁之前的行为
该注解是AspectJ中的注解，并不是spring提供的，所以还需要导入aspectjweaver.jar，aspectjrt.jar，除此之外还需要依赖aopalliance.jar
依赖包：
UserDao.java
配置文件 applicationContext.xml：
测试类：
1、 @Aspect
修饰Java类，指定该类为切面类。当spring容器检测到某个bean被@Aspect修饰时，spring容器不会对该bean做增强处理（bean后处理器增强，代理增强）
2、 @Before
修饰方法，before增强处理。用于对目标方法（切入点表达式表示方法）执行前做增强处理。可以用于权限检查，登陆检查。
常用属性：
value： 指定切入点表达式 或者引用一个切入点
对com.example.aop 包下所有的类的所有方法做 before增强处理：
结果：
如果同一条切入点表达式被使用多次，可以使用更友好的方式。定义一个切入点：
增强方法可以接受一个JoinPoint 类型的参数，用于获取被执行目标方法的一下属性。
结果：
3、 @AfterReturning
修饰方法，afterreturning增强处理。目标方法正常结束后做增强处理。
常用属性：
a、 pointcut/value：指定切入点表达式
b、 returning：指定一个参数名，用于接受目标方法正常结束时返回的值。参数名称需要在增强方法中定义同名的参数。
注意：
a、 如果使用了returning 。那么增强方法中的数据类型必须是返回结果的类型或者父类型，否则不会调用该增强处理。
b、 使用了returning 还可以用来 修改返回结果 。
以上面的例子来说，目标方法返回结果类型应该满足下面的条件
修改返回值：
结果：
可以看到 AfterReturning 修改了返回结果。
4、 @AfterThrowing
修饰方法，afterthrowing增强处理。当目标程序方法抛出 异常或者异常无法捕获时，做增强处理。
常用属性：
a、 pointcut/value ：指定切入点表达式
b、 throwing：指定一个形参，在增强方法中定义同名形参，用于访问目标方法抛出的异常
参数类型必须是 Throwable 的子类，同样也会有上面@AfterReturning 参数类型匹配的问题。
5、 @After
修饰方法 ，after增强处理。无论方法是否正常结束，都会调用该增强处理（@After= @AfterReturning+@AfterThrowing）。但是该增强方式无法获取目标方法的返回结果，也获取目标方法抛出的异常。所以一般用于进行释放资源，功能类似于 finally。
常用属性：
a、 value ：指定切入点表达式
结果：
从上面的结果来看 After 增加处理 ，因为不能接受返回结果作为参数，所以不能修改返回结果。
6、 @Around
修饰方法， around增强处理。该处理可以目标方法执行之前和执行之后织入增强处理（@Before+@AfterReturning）。
Around增强处理通常需要在线程安全的环境下使用，如果@Before和@AfterReturning可以处理就没必要使用@Around。
常用属性：
a、 value ：指定切入点表达式
当定义一个Aound增前处理时，增强方法第一形参需要时ProceedingJoinPoint类型。ProceedingJoinPoint有一个Object proceed()方法，用于执行目标方法。当然也可以为目标方法传递数组参数，来修改目前方法的传入参数。
around小结：
a、 Around增强处理通常需要 在线程安全 的环境下使用
b、 调用 proceed()可以获取返回结果，所以可以修改目标方法的返回值
c、 proceed(Object[] var1) 可以修改入参，修改目标方法的入参
d、 可以进行目标方法执行之前和执行之后织入增强处理
around 和 afterReturning 都可以修改返回结果。不过两者的原理不同：
a、 around：可以任意修改，或者返回不相关的值。这个返回值完全可以自主控制
b、 afterReturning，通过方法参数 ，使用对象引用的方式来修改对象。修改对象引用地址那么修改时无效的
除此之外从输出结果来看，增强处理是有序的：
around 和 afterReturning小结：
a、 只有 around 和 afterReturning 可以获取并修改返回结果。需要注意两种方式修改的区别。
b、 around 需要线程安全
c、 虽然增强处理都需要 切入点表达式，并不是都支持 pointcut 属性，所以最好都是用value 属性指定。当注解只需要value属性时，value可以省略
7、 @Pointcut
修饰方法，定义一个切入点表达式用于被其他增强调用。使用该方式定义切入点方便管理，易复用。
切入点方法定义和测试方法定义类似，具有以下特点：
a、 无返回值 （void）
b、 无参数
c、 方法体为空
d、 方法名就是切入点名称
e、 方法名不能为 execution
切入点表达式
切入点表达式可以通过 、 || 、 ! 连接
1）、execution 表达式：
2）、within 表达式：
a、匹配指定类下的所有方法。
b、匹配执行包及其子包下所有类的所有方法。
所以within可以看做execution的简写，不需要指定返回类型、方法名、参数（ 最小作用单位是类 ）
3）、 @annotation：匹配使用指定注解修饰的目标方法；
匹配使用@CustomMethodAnnotation注解的目标方法。
4）、 @within: 用于匹配使用指定注解修饰的类下的所有方法
within 作用范围是类，@within的作用范围与其一致。不同的是@within 指定的不是类而是注解
匹配使用@ResponseBody 注解的类 下的所有方法。
AOP小结：
1）、 Around增强处理通常需要 在线程安全 的环境下使用
2）、 使用 around 和 afterReturning 可以获取并修改返回结果
3）、 增强处理指定 切入点表达式时，最好使用value 属性
4）、 切入点 名称（方法名）不能为 execution
5）、 AfterReturning 指定了 returning 属性接受目标方法返回结果，注意 参数类型需要和返回结果类型一致（满足 resutType instanceof argsType ）
增强方式的顺序：
1、 @Bean(name=“xxx”)
修饰方法，该方法的返回值为spring容器中管理的bean。当然该注解和上面的@Component效果一样，主要用于做区分。
@Bean 通常使用在 @Configuration 修饰的配置类中，该注解功能相当于 元素
常用的属性：
a、 name：bean id 。name可以省略，省略时bean名称为方法名。也可以指定多个名称（逗号隔开）。
b、 autowire： 是否自动注入，默认Autowire.NO
c、 initMethod：bean的初始化方法。在依赖注入之后执行
d、 destroyMethod: spring容器关闭时bean调用的方法
当然 @Bean 还可以配合 @Scope 指定bean的作用域
2、 @ConfigurationProperties
用于从属性文件中获取值 application.properties 或者 application.yml 。当然了 如果在配置文件中引入其他配置文件，也可以获取到属性值。
包含的属性：
a、 value | prefix 两者互为别名。指定前缀，默认为""
b、 ignoreUnknownFields：默认为true。是否忽略未知字段，当实体中的字段在配置文件中不存在时，是忽略还是抛出异常
c、 ignoreInvalidFields： 默认false。 是否忽略不合法的字段，此处的不合法是指类型不合适，配置文件中存在改配置但是无法转化为指定的字段类型。
Mybatis属性配置
application.properties：
ConfigurationProperties 可以配置前缀，然后会根据实体的变量名拼接前缀，去配置文件中查询配置。
3、 @Configuration
修饰一个Java类，被修饰的类相当于一个xml配置文件。功能类似于 。在springboot中大量使用了该注解，该注解提供了一种使用Java类方式配置bean。
可以发现 @Configuration使用了@Component 注解修饰。
实例 ：
配置Mybatis会话工厂
4、 @Import
功能和 类似，修饰Java类，用于向当前类导入其他配置类。 可以导入多个配置文件，通常用于导入不在包扫描范围内的配置文件。可以被扫描的配置类可以直接访问，没有必要使用@Import 导入。
比如 SpringBoot的启动类指定的包扫描路径为 com.example
数据库的配置文件在 com包下。
在MyBatisConfig 中引入 DataSourceConfig， 就会解析DataSourceConfig。将解析出的Bean交给容器管理
5、 @ImportResource
修饰Java类，用于向类引入xml配置文件。
用于导入包含bean定义的配置文件，功能和 类似。默认情况下可以处理后缀为 .groovy 和.xml 的配置文件
6、 @Value("${expression}")
修饰成员变量或者 方法、构造器的参数，用于属性值注入（在配置文件中配置的值）。
注意: @Value不能对 static 属性注入。
如果的确需要注入到静态变量，可以通过以下方式间接进行注入：
1）、设置一个私有静态 实例
2）、通过构造函数或者 @PostConstruct 注解为 静态实例 赋值，指向本身（this）
3）、对成员属性注入内容
4）、提供静态方法，使用静态实例获取成员属性
7、@PropertySource(value=“classpath:jdbc.properties”)
该注解用来加载属性文件。
常用属性：
a、 ignoreResourceNotFound： 当资源文件找不到的时候是否会忽略该配置，而不是抛出错误。一般用于可选项
b、 encoding ： 资源文件使用什么编码方式
c、 value ： 指定属性文件位置。可以配置多个属性文件，不可以使用通配符。
在 PropertySource 中可以指定多个路径，并且会将属性文件中的值加载到 Environment 中。
@ConfigurationProperties 和 @PropertySource
它们的使用有一些差异：
1）、 @PropertySource 使用该注解加载的是 相对独立的属性文件，可以同时加载多个文件 （xxx.properties），而且 不支持自动注入 ， 不支持前缀注入
2）、 @ConfigurationProperties 用于加载配置文件（application.properties | application.yml）。该注解功能更强大：
a、 支持前缀注入 （ prefix ）
b、 相同属性名的自动注入
c、 $("") 支持EL表达式注入
应用实例：
在以往的开发中通常会将数据库连接信息存放在单独的属性文件中（jdbc.properties）。而在spring boot 中我们会将数据库的信息存放在配置文件中，这会极大便利开发工作。
jdbc.properties：
可以通过 @Value 注解将配置文件的值注入到实体类中
也可以注入Environment ，通过Environment 获取值
1、 @ResponseBody
控制器方法返回值会使用 HttpMessageConverter 进行数据格式化，转化为JSON字符串。
同样的 ResponseBodyAdvice: 针对使用@ResponseBody的注解的类，方法做增强处理。
2、 @RestController
@RestController = @Controller + @ResponseBody ， 所以通常直接使用@RestController 注解
3、 @RequestBody
从Reuqest请求体中获取内容，绑定到方法的指定参数上。 SpringMVC 使用HttpMessageConverter 接口将请求体中的数据转化为方法参数类型。
SpringMVC 给用户对参数的处理提供了很大支配权。 我们可以使用 接口RequestBodyAdvice 来实现对参数进行拦截处理。
注意
1）、 RequestBodyAdvice : 针对所有以@RequestBody的参数做处理
2）、 自定义的处理对象类上必须得加上@ControllerAdvice注解!
利用此功能我们可以做以下处理工作：
1）、参数做解密处理。
2）、修改接受的参数数据。
4、 @RequestParam
从Request请求中获取指定的参数。
可以设置的属性：
1）、 required ： 默认为true 参数必须存在 。参数不存在时抛出异常(MissingServletRequestParameterException). 提示信息
2）、 defaultValue ： 设置参数默认值。 当参数没有提供或者为空值时生效, 包含隐式定义 required=false
3）、 name | value ， 互为别名的属性， 绑定请求中的参数名。 request.getParameter(name);
5、 @RequestMapping
用于设置 请求 和 Method 的映射关系。指明何种请求可以和方法匹配
可配置属性值：
1）、 path、value、 name, 互为别名，设置可以处理的url。
2）、 consumes，字符串数组。 指定可以处理的 媒资类型，仅当请求头中的 Content-Type 与其中一种媒体类型匹配时，才会映射请求。所以该配置会缩小可匹配的请求。 当url 匹配但是consumes不匹配时， 状态码415。 不设置的话，表示不限制媒资类型，参数的具体使用何种方式解析，SpringMVC会选择合适的处理器处理。
3）、 produces，字符串数组。 生成的媒资类型，该属性会影响实际的输出类型。和consumes一样，改配置会缩小匹配的范围。 只有当请求头中的 Accept 与 配置的任意一个媒资类型匹配时，才会映射请求。 当url 匹配与consumes不匹配时， 状态码406 。 比如：为了生成UTF-8编码的JSON响应，应使用 MediaType.APPLICATION_JSON_UTF8_VALUE。
SpringBoot注解介绍
1、@ComponentScan：
新建SpringBoot项目时 会自动生成一个入口类 命名规则是项目名+Application 该类上面有个@SpringBootApplication 项目启动时系统会自动扫描这个类的同级以及下级目录 将需要的对象注入到IOC容器 在需要时通过DI(依赖注入)注入到需要的对象中 那么问题来了 程序是怎么确定需要扫描哪些包呢 这是因为在@SpringBootApplication中有个注解 如图：
通过该注解上的配置 才能准确定位需要扫描哪些包 。
由此我们可以进行延伸 如果我们需要臊面的资源不再该类的同级或者下级 我们只需要在项目入口类上配置上@ComponentScan("资源路径")
就可以将我们需要的外部（其他路径）资源加载到IOC容器中了
2、@Qualifier("byname") 通过name名 注入
3、@Primary 对于同一个类型下有多个实现 该注解可以标明哪个实现类是优先被注入的 如图：
此时会优先注入带有@Primary注解的bean 如下图：
4、@ConditionalOnProperty 该注解可以读取配置文件 根据配置文件的值来决定是否将bean注入到容器中
该注解中的三个参数：value 值为配置文件中配置项的名字 havingValue为值 matchIfMissing 的值为true和false 时针对没有配置项的情况下时是否注入
5、
@Getter lombok为实体类自动生成getter方法
@Setter lombok为实体类自动生成setter方法
@AllArgsConstructor lombok为实体类自动生成全参数构造方法
@NoArgsConstructor lombok为实体类自动生成无参数构造方法
@RequiredArgsConstructor lombok为实体类自动生成成员变量非空的参数构造方法
@NonNull lombok为实体类指定参数非空
实体类.builder().name("muse").age(18).build()可以替换之前的setter方法赋值 不过需要在实体类上增加@Builder注解
但是一旦使用@Builder 就无法通过构造方法去实例化bean 因为@Builder会生成一个私有的构造方法 如果想使用构造方法实例化 可以配合使用NoArgsConstructor 或者手动新增一个无参构造
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 方法，见名知意，这个就是去创建应用上下文对象：
注意这里通过反射实例化了一个新的没见过的上下文对象 AnnotationConfigServletWebServerApplicationContext ，这个是SpringBoot扩展的，看看其构造方法：
如果你有看过Spring注解驱动的实现原理，这两个对象肯定不会陌生，一个实支持注解解析的，另外一个是扫描包用的。
上下文创建好了，下一步自然就是调用refresh方法启动容器：
这里首先会调用到其父类中 ServletWebServerApplicationContext ：
可以看到是直接委托给了父类：
这个方法不会陌生吧，之前已经分析过了，这里不再赘述，至此SpringBoot的容器就启动了，但是Tomcat启动是在哪里呢？run方法中也没有看到。
实际上Tomcat的启动也是在refresh流程中，这个方法其中一步是调用了onRefresh方法，在Spring中这是一个没有实现的模板方法，而SpringBoot就通过这个方法完成了Tomcat的启动：
这里首先拿到 TomcatServletWebServerFactory 对象，通过该对象再去创建和启动Tomcat：
上面的每一步都可以对比Tomcat的配置文件，需要注意默认只支持了http协议：
如果想要扩展的话则可以对 additionalTomcatConnectors 属性设置值，需要注意这个属性没有对应的setter方法，只有 addAdditionalTomcatConnectors 方法，也就是说我们只能通过实现 BeanFactoryPostProcessor 接口的 postProcessBeanFactory 方法，而不能通过 BeanDefinitionRegistryPostProcessor 的 postProcessBeanDefinitionRegistry 方法，因为前者可以通过传入的BeanFactory对象提前获取到 TomcatServletWebServerFactory 对象调用 addAdditionalTomcatConnectors 即可；而后者只能拿到BeanDefinition对象，该对象只能通过setter方法设置值。
这段代码会在控制台打印所有的事件名称，按照顺序如下：
以上是正常启动关闭，如果发生异常还有发布 ApplicationFailedEvent 事件。事件的发布遍布在整个容器的启动关闭周期中，事件发布对象刚刚我们也看到了是通过SPI加载的 SpringApplicationRunListener 实现类 EventPublishingRunListener ，同样事件监听器也是在 spring.factories 文件中配置的，默认实现了以下监听器：
可以看到有用于文件编码的（ FileEncodingApplicationListener ），有加载日志框架的（ LoggingApplicationListener ），还有加载配置的（ ConfigFileApplicationListener ）等等一系列监听器，SpringBoot也就是通过这系列监听器将必要的配置和组件加载到容器中来，这里不再详细分析，感兴趣的读者可以通过其实现的 onApplicationEvent 方法看到每个监听器究竟是监听的哪一个事件，当然事件发布和监听我们自己也是可以扩展的。
SpringBoot最核心的还是自动配置，为什么它能做到开箱即用，不再需要我们手动使用 @EnableXXX 等注解来开启？这一切的答案就在 @SpringBootApplication 注解中：
这里重要的注解有三个： @SpringBootConfiguration 、 @EnableAutoConfiguration 、 @ComponentScan 。 @ComponentScan 就不用再说了， @SpringBootConfiguration 等同于 @Configuration ，而 @EnableAutoConfiguration 就是开启自动配置：
@AutoConfigurationPackage 注解的作用就是将该注解所标记类所在的包作为自动配置的包，简单看看就行，主要看 AutoConfigurationImportSelector ，这个就是实现自动配置的核心类，注意这个类是实现的 DeferredImportSelector 接口。
在这个类中有一个 selectImports 方法。这个方法在我之前的文章这一次搞懂Spring事务注解的解析也有分析过，只是实现类不同，它同样会被 ConfigurationClassPostProcessor 类调用，先来看这个方法做了些什么：
追踪源码最终可以看到也是从 META-INF/spring.factories 文件中拿到所有 EnableAutoConfiguration 对应的值（在 spring-boot-autoconfigure 中）并通过反射实例化，过滤后包装成 AutoConfigurationEntry 对象返回。
看到这里你应该会觉得自动配置的实现就是通过这个 selectImports 方法，但实际上这个方法通常并不会被调用到，而是会调用该类的内部类 AutoConfigurationGroup 的process和selectImports方法，前者同样是通过 getAutoConfigurationEntry 拿到所有的自动配置类，而后者这是过滤排序并包装后返回。
下面就来分析 ConfigurationClassPostProcessor 是怎么调用到这里的，直接进入 processConfigBeanDefinitions 方法：
前面一大段主要是拿到合格的 Configuration 配置类，主要逻辑是在 ConfigurationClassParser.parse 方法中，该方法完成了对 @Component 、 @Bean 、 @Import 、 @ComponentScans 等注解的解析，这里主要看对 @Import 的解析，其它的读者可自行分析。一步步追踪，最终会进入到 processConfigurationClass 方法：
这里需要注意 this.conditionEvaluator.shouldSkip 方法的调用，这个方法就是进行Bean加载过滤的，即根据 @Condition 注解的匹配值判断是否加载该Bean，具体实现稍后分析，继续跟踪主流程 doProcessConfigurationClass ：
这里就是完成对一系列注解的支撑，我省略掉了，主要看 processImports 方法，这个方法就是处理 @Import 注解的：
刚刚我提醒过 AutoConfigurationImportSelector 是实现 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启动器，相信看完本篇应该难不倒你。
springboot常用注解
springboot常用注解有@SpringBootApplication；@Repository；@Service；@RestController；@ResponseBody。
1、Spring Boot 是 Pivotal 团队在 Spring 的基础上提供的一套全新的开源框架，其目的是为了简化 Spring 应用的搭建和开发过程。Spring Boot 去除了大量的 XML 配置文件，简化了复杂的依赖管理。Spring Boot 具有 Spring 一切优秀特性，Spring 能做的事，Spring Boot 都可以做，而且使用更加简单，功能更加丰富，性能更加稳定而健壮。
2、@SpringBootConfiguration注解，继承@Configuration注解，主要用于加载配置文件。@SpringBootConfiguration继承自@Configuration，二者功能也一致，标注当前类是配置类， 并会将当前类内声明的一个或多个以@Bean注解标记的方法的实例纳入到spring容器中，并且实例名就是方法名。
3、starter 是 SpringBoot 中一种非常重要的机制，它可以繁杂的配置统一集成到 starter 中，我们只需要通过 maven 将 starter 依赖引入到项目中，SpringBoot 就能自动扫描并加载相应的默认配置。starter 的出现让开发人员从繁琐的框架配置中解放出来，将更多的精力专注于业务逻辑的开发，极大的提高了开发效率。
Springboot(四):springboot的注解有哪些注解
springboot的优点就是简化配置,,没有了xml,基本都是一个配置(application.properties)+注解来实现springboot的构建
那么都有哪些注解咧?说一下我在工作中常用的注解
1:##@SpringBootApplication
标识该类为SpringBoot项目启动类。并且让SpringBoot自动给程序进行必要的配置，等同于@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan这三个注解.
(1):@SpringBootConfiguration表示的是该类会作为Springboot的一个配置类，
(2):@EnableAutoConfiguration表示开启自动配置功能,里面也实现了自动配置原理
@Configuration会把组件会装配到实体类上封装为一个bean,AutoConfigurationImportSelector的selectImports()这个方法,找到所有JavaConfig自动配置类的全限定名对应的class，然后将所有自动配置类加载到Spring容器中。bean有了,配置有了,相当于对象也有了,这就是自动配置.
(3):@ComponentScan用来将包加入SpringIOC的包扫描，
2: @RestController 和@Controller
@RestController相当于@Controller+@ResponseBody,
@RestController加在类上面的注解，使得类里面的每个方法都将json/xml返回数据加返回到前台页面中。
比如return "abc" 前端会展示abc三个字母
@Controller加在类上面的注解，使得类里面的每个方法都返回一个视图页面。
比如return "abc" 前端会展示静态资源中的的abc.html里面的内容
3: @component和@configuration
虽然Component注解也会当做配置类，但是并不会为其生成CGLIB代理Class，所以在生成Driver对象时和生成Car对象时调用car()方法执行了两次new操作，所以是不同的对象。当时Configuration注解时，生成当前对象的子类Class，并对方法拦截，第二次调用car()方法时直接从BeanFactory之中获取对象，所以得到的是同一个对象。
4: @Autowired 与@Resource
@Resource和@Autowired都是做bean的注入时使用，其实@Resource并不是Spring的注解，它的包是javax.annotation.Resource，需要导入，但是Spring支持该注解的注入。
@Autowired注解是按照类型（byType）装配依赖对象，默认情况下它要求依赖对象必须存在，如果允许null值，可以设置它的required属性为false。如果我们想使用按照名称（byName）来装配，可以结合@Qualifier注解一起使用
@Resource默认按照ByName自动注入，由J2EE提供，需要导入包javax.annotation.Resource。
SpringBoot的核心注解都有哪些？
@SpringBootApplication注解是SpringBoot的灵魂注解
这个注解整合了3个注解的特性：分别是@Configuration注解、@Component注解、@EnableAutoConfiguration注解。这个三个注解的作用分别是：
- @Configuration注解：声明当前类为配置类
- @ComponentScan注解：指定扫描包路径，默认不填扫描当前包及其子包
- @EnableAutoConfiguration注解：最重要注解没有之一，打开SpringBoot的自