SpringBoot自动配置的原理及实现SpringBoot之@Import注解正确使用方式

这是一般规范配置事务的，根据业务需求可以改expression路径，和前缀方法

从我这个配置文件来讲，事务是从service。前缀方法（）开始给这个方法添加事务，而这个方法的实现是在serviceImpl类里，这个类里你又调用了dao。XXX方法等很多 *** 作，但因为从第一入口类(就是你调用那个service。前缀方法)开始已经开启了一个事务，当然先开启session 然后对应N个事务，而这个session又管理到你执行完最后方法（比如你的dao的查询，更新等），到你这个入口类方法结束出来时候 spring给你管理事务的commit和session的关闭。具体怎么封装好的我也不清楚，但你要注意的是上面配置的每个属性代表什么意思，注重的是什么时候开启事务，什么时候不开启事务等

希望对你有所帮助

使用configurationProperties注解并指明在配置文件中的前缀，然后用component注解注册进ioc容器。

我这里定义的两个静态内部类，同时创建了各自的实例，比如这个Email静态内部类中有三个属性，那么配置文件就可以是mqmyrabbitemailqueue来对静态内部类中的属性进行一个映射

在yml中写配置

项目编译后，在yml中写配置会自动显示出来自己定义的配置映射类所具有的属性，如下图所示：

然后在yml配置文件中，写各个配置，配置类就会读取到了

在spring的xml配置文件中，在头部会出现如下的东西

这些奇怪的xmlns和很长的url的作用是什么呢？

首先，介绍一下 xmlns 的作用，如下所示，一个 xml 文档中如果包含如下两种定义不同， 但是名称相同的元素， xml 解析器是无法解析的， 因为它不能确定当你调用documentgetElementsByTagName("book") 时应该返回哪个元素。

这时候可以通过在名称增加前缀解决这个问题

由此，引入一个概念 命名空间 ，通过增加前缀表示不同的那是不同命名空间下的table，从而解决了矛盾，但是不同的人都有自己创建的不同的命名空间来描述同样的东西，不利于xml文件信息的解析，比如说，同样都是水果，可以从颜色和香味不同角度来定义成如下两种形式：

为此，w3c(万维网联盟)对于一些类型，定义了对应的命名空间和这些类型的标准，xml解释器碰到这些类型的时候就会通过这些标准去解析这类型的标签，为了确保命名空间的唯一，所以不同的命名空间的通常使用URL作为被识别的id，如下例子:

这句话的作用是当前引入了一个叫做xsi的命名空间，xsi可以在接下来要使用该命名空间时所使用的，如下:

而 >

prefix 代表属性文件中的前缀， @PropertySource 指定加载的那个属性文件，如是默认的applicationproperties 则不用指定。

springboot 15以后的版本，不支持 @ConfigurationProperties(prefix = "config2",locations="classpath:testproperties") locations这种写法，使用@PropertySource

使用时，通过依赖注入得到单例

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/springfactories 文件中加载对应的实现类并实例化，SpringBoot的自动配置也是这样实现的。

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

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

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

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

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

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

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

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

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

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

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

以上就是关于SpringBoot自动配置的原理及实现/SpringBoot之@Import注解正确使用方式全部的内容，包括:SpringBoot自动配置的原理及实现/SpringBoot之@Import注解正确使用方式、SpringBoot配置、spring的事务配置等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！