公司网站需要多少钱,wordpress ico图标像素,网站的模块,天津建设工程新希望目录 前言阅读对象阅读导航前置知识笔记正文0、什么是自动配置0.1 基本概念0.2 SpringBoot中的【约定大于配置】0.3 从SpringMVC看【约定大于配置】0.4 从Redis看【约定大于配置】 一、EnableAutoConfiguration源码解析二、SpringBoot常用条件注解源码解析2.1 自定义条件注解2.… 目录 前言阅读对象阅读导航前置知识笔记正文0、什么是自动配置0.1 基本概念0.2 SpringBoot中的【约定大于配置】0.3 从SpringMVC看【约定大于配置】0.4 从Redis看【约定大于配置】 一、EnableAutoConfiguration源码解析二、SpringBoot常用条件注解源码解析2.1 自定义条件注解2.2 ConditionalOnClass原理解析2.3 ConditionalOnBean原理解析 三、SpringBoot之Mybatis自动配置源码解析四、SpringBoot之AOP自动配置源码解析五、SpringBoot Jar包启动过程源码解析 学习总结感谢 前言
想要搞懂自动装配需要当前系列前两篇笔记内容打底。不过我上一篇笔记写的不好没有什么突出的重点主要也是当时跟着课程看了源码之后也没发现什么特别的直到在看自动装配源码的时候才后知后觉遗漏了一些重要的知识点。但是总体来说不影响这一节课的笔记记录吧。
阅读对象
阅读导航
系列上一篇文章《【微服务专题】Spring启动过程源码解析》
前置知识
笔记正文
0、什么是自动配置
我们说起SpringBoot总会不自觉的联想到自动配置、约定大于配置等标签但说实在我是有一点困惑的这个【约定和配置】到底是什么意思或者说它们具体指的是哪些内容啊 我在想像我这种只是用过那么一年多SSM/SSH甚至完全没有经历过的人来说是很难理解的。虽然我也确实经历过SSM/SSH但那时候初出茅庐根本就没在意过这些玩意好吧…
不过话说回来后面再回来继续做Java的时候已经是SpringBoot的时代了嘛所以单从片面印象来说的话SpringBoot确实方便了很多。最最最直观的就是启动给我的感觉启动一个web应用跟简单运行了一个main方法一样便捷。而在以前SSM/SSH时代各种眼花缭乱的xml配置还有那个令人烦躁的tomcat配置就已经让我很难受了。
好吧不懂嘛于是我就去稍微学习了一下。下面我就按照我自己的理解再拼上一些百度的、起码能说服我自己的答案给大家说道说道。另外也想举一个真正直观的例子给大家说说【约定和配置】到底使了什么魔法
0.1 基本概念
【约定大于配置】是一种开发思想、设计理念它强调使用默认约定和规则减少开发者需要做的【显式】配置。根据这一原则大部分情况下开发者只需关注那些【不符合默认约定】的配置而不需要为每个细节都进行显式配置。。 开天眼给大家说一下既然结果是减少了需要程序员【显示】配置的工作量那反过来就证明了在SpringBoot之前的时代有一些配置是不得不必须需要程序员去配置的 另外这里说的【配置】不是指xml配置而是对引入的服务的所有形式的配置xml只是一种介质而已我们还可以是txt、yml还有java文件的配置方式。 我认为这个结论很重要我后面研究案例就是往这方向去看的 综上所述可以这样简单地理解【约定】和【配置】
默认规则【显示】配置不得不设置的配置 / 没办法使用默认规则的配置。这里说的【配置】不是指具体的xml配置而是对引入的服务的【所有形式】的配置xml只是其中一种形式而已配置还可以是txt、yml包括java文件的配置形式。
这个理念有如下显著的优势
提高开发效率 通过遵循默认约定开发者可以快速启动项目并进行开发无需花费大量时间在繁琐的配置上减少决策负担 【约定大于配置】减少了开发者需要做出的决策使开发过程更加流畅不需要在每个细节上做出选择减少错误 默认约定可以减少配置错误的机会因为开发者只需要在特定情况下进行配置从而降低了出错的可能性
0.2 SpringBoot中的【约定大于配置】
我们都知道SpringBoot是基于Spring的严格来说SpringBoot的出现其实是为了降低Spring的使用门槛。
使用maven的目录结构。默认有src-main-resources文件夹存放资源配置文件src-main-java存放项目java源码target文件夹存放编译、打包内容其实Maven的设计本身就是遵循【约定大于配置】的原则 这是约定的一种通过约定这些内容使得项目结构统一减少了开发人员学习成本。 试想一下如果我们在不同的公司他们的项目结构五花八门甚至没有src/main/resources没有src/main/java等目录你学习成本是不是变高了博主之前写过2、3年C/C那时候接触的项目就是这个鸟样子的都是自定义资源存放目录打包目录源码目录真的吐血… … 我转战Java很大一个原因就是奔着Java的规范性去的。当然我现在相当后悔… 使用application.properties/yml文件设置配置内容 这也是一种约定拒绝程序员五花八门的配置文件 默认使用Tomcat容器 接触过SSM吗SSM项目通常来说需要额外配置启动一个Tomcat然后将SSM项目打包部署到Tomcat上 而在SpringBoot中我们启动项目就跟运行一个普通的main函数一样 提供了大量的自动配置接口自动配置类注解等帮助程序员配置。严格来说自动配置接口以及注解等都是为了自动配置类服务的。SpringBoot提供的大量自动配置类在里面默认设置了很多值用以配置第三方接口服务这些默认配置甚至能让开发做到开箱即用只有一些不得不需要用户设置的内容才需要开发人员自己设置。这就是上面概念所谓的开发者只需要关注那些不符合默认约定的配置的意义。 这是SpringBoot【约定大于配置】的重要实现。我们先稍微解释一下这些所谓的接口、类、注解是指什么 自动配置接口AutoConfigurationImportFilter、AutoConfigurationImportListener等自动配置类DispatcherServletAutoConfiguration、HttpEncodingAutoConfiguration等注解诸如AutoConfiguration、AutoConfigurationPackage等 上述我只是简单列举了一些内容而已其实具体的可以看org.springframework.boot:spring-boot-autoconfigure这个包。里面就是SpringBoot为大家做自动配置提供的默认配置和相关接口 0.3 从SpringMVC看【约定大于配置】 说实在SpringMVC我不是很熟悉所以我不是很保证自己说的是对的在网上也没看到非常令人信服的答案。但是关于【约定大于配置】的体现我觉得还是正确的。 有人说spring-boot-starter-web其实就是面配置的SSM。在SSM时代我们想要开发一个web应用免不了如下配置
新增web.xml在里面配置前端控制器DispatcherServlet、视图解析器ViewResolver、过滤器等新增核心配置文件**-servlet.xmlTomcat容器的配置等等…
其实说需要新增这种那种xml配置是有点狭隘的说法我前面说过了xml只是其中一种配置形式而已。 准确来说传统的SSM项目需要我们开发人员显式、准确地向Spring容器注册DispatcherServlet、ViewResolver、SqlSessionFactoryBean、DriverManagerDataSource。 如果我们没有【显式】地去声明、注册这些Bean那我们项目直接启动失败他会说找不到这个找不到那个。但是在SpringBoot中我们只需要在pom中引入spring-boot-starter-web就可以了这个jar包会自动向Spring中注册上述关键bean。
怎么注册我们简单看一下关于SpringMVC的自动配置类。
1WebMvcAutoConfiguration.javaSpringMVC的自动配置入口 在这里我们无需关心上面的诸多注解的具体含义先具体意义我会在后面的源码解析中介绍。 但是可以预见的是在某种情况下spring-boot-stater-web会进入DispatcherServletAutoConfiguration.class里面
2DispatcherServletAutoConfiguration.java在这里有一个Bean暂不关心他什么时候会被触发但至少可以预见的是在某种情况下DispatcherServletAutoConfiguration类会向Spring中注册一个DispatcherServlet类型的bean 啊对的本质上就是如此而已。SpringBoot的自动配置实际上就是SpringBoot的源码中预先写好了一些配置类预先定义好了一些Bean我们在用SpringBoot时这些配置类就已经在我们项目的依赖中了而这些自动配置类或自动配置Bean到底生不生效就看具体所指定的条件了。
不过还有一点需要说明那就是SpringBoot可不是简简单单的给你注册了一个默认的bean它还会给部分【符合约定】的基础参数设置默认的、至少有意义的、比较符合一般应用的初始值来初始化bean。这个就是SpringBoot提供的各种XxxProperties.java。例如WebMvcProperties O对了说到了这个XxxProperties.java文件其实它也是约定的一种体现。以前SSM我们相当于直接配置了服务接口的一些参数而在SpringBoot里面我们直接配置的其实是XxxProperties然后再由SpringBoot使用XxxProperties配置属性去初始化服务接口参数。而通常这些XxxProperties对应的是application.properties里面的一些配置内容。 相比起直接配置服务接口参数XxxProperties可读性更强使用也更简单。
0.4 从Redis看【约定大于配置】
省略
OK关于SpringBoot中的【约定大于配置】就介绍到这里了。那他们是怎么实现的呢有经验的朋友或者稍微细心的朋友估计也从上图看到了主要是靠下图这些类、接口、注解org.springframework.boot:spring-boot-autoconfigure包下
一、EnableAutoConfiguration源码解析
二、SpringBoot常用条件注解源码解析
SpringBoot中的常用条件注解有
ConditionalOnBean是否存在某个某类或某个名字的BeanConditionalOnMissingBean是否缺失某个某类或某个名字的BeanConditionalOnSingleCandidate是否符合指定类型的Bean只有一个ConditionalOnClass是否存在某个类ConditionalOnMissingClass是否缺失某个类ConditionalOnExpression指定的表达式返回的是true还是falseConditionalOnJava判断Java版本ConditionalOnWebApplication当前应用是不是一个Web应用ConditionalOnNotWebApplication当前应用不是一个Web应用ConditionalOnPropertyEnvironment中是否存在某个属性当然我们也可以利用Conditional来自定义条件注解
条件注解是可以写在类上和方法上的如果某个条件注解写在了自动配置类上那该自动配置类会不会生效就要看当前条件能不能符合或者条件注解写在某个Bean修饰的方法上那这个Bean生不生效就看当前条件符不符合。
具体原理是
Spring在解析某个自动配置类时会先检查该自动配置类上是否有条件注解如果有则进一步判断该条件注解所指定的条件当前能不能满足如果满足了则继续解析该配置类如果不满足则不进行解析了也就是配置类所定义的Bean都得不到解析也就是相当于没有这些Bean了。同理Spring在解析某个Bean的方法时也会先判断方法上是否有条件注解然后进行解析如果不满足条件则该Bean不会生效
2.1 自定义条件注解
SpringBoot中众多的条件注解都是基于Spring中的Conditional来实现的我们先来用一下Conditional注解。 先来看下Conditional注解的定义
/*** * 指示组件只有在所有指定条件匹配时才有资格注册。* 条件是可以在注册bean定义之前以编程方式确定的任何状态(有关详细信息请参阅条件)。* Conditional注释可以以以下任何一种方式使用:* 在任何直接或间接用Component注释的类(包括Configuration类)上作为类型级注释* 作为元注释用于组合自定义构造型注释* 作为任何Bean方法上的方法级注释* 如果Configuration类被标记为Conditional那么与该类关联的所有Bean方法、Import注释和ComponentScan注释* 将受这些条件的约束。*/
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 ShenCondition implements Condition {Overridepublic boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {MapString, Object component metadata.getAnnotationAttributes(org.springframework.stereotype.Component);System.out.println(下面开始打印condition里面的内容);System.out.println(component);Object value component.get(value);return value.toString().equals(shen);}
}上面这个实现类很简单就是获取被Conditional(ShenCondition.class)注解的类上获取它Component上的注解值如果值是shen那就返回true否则bean注册不成功。测试用例如下
Conditional(ShenCondition.class)
Component(shen)
public class ShenWorker {public String sayHello() {return hello;}
}SpringBootApplication(scanBasePackages org.example.springboottest)
public class ShenMyApplication {public static void main(String[] args) {ConfigurableApplicationContext context SpringApplication.run(ShenMyApplication.class);ShenWorker shen (ShenWorker) context.getBean(ShenWorker.class);System.out.println(------------------------);System.out.println(shen.sayHello());}
}此时运行控制台输出 把上面的ShenWorker 的Component值改成其他如Component(shenWorker)运行则输出如下 报错了NoSuchBeanDefinitionException。 我想到了这里大家应该多少知道Conditional注解的作用了接下来我们挑其中一两个SpringBoot声明的条件注解看一下源码剖析一下它是怎么实现的。
2.2 ConditionalOnClass原理解析 ConditionalOnClass注解的作用是校验是否存在某个类。 Spring这种优秀源码通常注释都是很完善的我们先来看看它们是怎么定义的
/*** Conditional当且仅当指定的类在类路径上时才匹配成功** value()可以在Configuration类上安全地指定因为在加载类之前* 会使用ASM解析注释元数据。当放置在Bean方法上时需要特别注意* 考虑在单独的Configuration类中隔离条件特别是如果方法的返回类型与条件的目标匹配*/
Target({ ElementType.TYPE, ElementType.METHOD })
Retention(RetentionPolicy.RUNTIME)
Documented
Conditional(OnClassCondition.class)
public interface ConditionalOnClass {/*** 必须设置的class信息。* 因为这个注释是通过加载类字节码来解析的classLoader.loadClass* 当且仅当这个注解直接作用在bean上而不是当这个注解被用作组合的元注释时* 在这里指定最终可能不在classpath上的类是安全的不会报错。* 想要将此注解用作元注释那么就只使用name属性*/Class?[] value() default {};/*** 必须设置的类全限定名*/String[] name() default {};
}根据我们自定义注解经验该注解的实现肯定是在Conditional(OnClassCondition.class)的OnClassCondition.class中。 顺便在这里介绍一下怎么用idea追踪代码吧。
1寻找关键实现类 首先我们知道OnClassCondition.class实现自Condition接口主要是实现里面的matches()方法。虽然咱还不知道它是在哪里被Spring调用的但起码他肯定是会被调用的对吧所以我们先跳到OnClassCondition.class文件打开它的继承图如下所示 可以发现它继承或者实现了各种各样的接口其中一个是Condition。那OK 我们在回到OnClassCondition.class文件alft7打开代码结构图然后在右上角点击查看继承过来的属性、方法如下所示 如上图所示绿色框内灰色的即为继承过来但是没有重写的方法。可以看到Condition接口的matches方法就没有被重写过那说明父类中肯定有默认的实现类点击一下会跳到SpringBootCondition类中它的默认实现方式如下 可以看到最重要的是红框内的2行代码。点击getMatchOutcome发现这是一个抽象方法所以又回到OnClassCondition.class文件中查找一下看看是否实现或者重写了该方法。最后发现如下 重写了再结合之前的代码可以判断出来这里就是OnClassCondition类的逻辑实现核心。上面的代码其实也不难基本上通过方法名就知道啥意思了。主要原理就是使用反射工具根据权限定名去JVM加载类。 特别注意ConditionalOnClass和ConditionalOnMissingClass注解的核心实现都是这个类的这个方法 2.3 ConditionalOnBean原理解析
点击查看ConditionalOnBean注解会发现逻辑是在OnBeanCondition.class中然后按照上面的思路也会发现它跟前面的注解基本一致实现逻辑也是在getMatchOutcome中如下 这个源码略显复杂但是可以通过阅读注解接口的各种字段信息推断出来具体过程。总的来说就是根据bean是否存在来返回结果。 特别注意ConditionalOnBean和ConditionalOnSingleCandidateConditionalOnMissingBean注解的核心实现都是这个类的这个方法 三、SpringBoot之Mybatis自动配置源码解析
在我们的项目pom中导入如下 dependencygroupIdorg.mybatis.spring.boot/groupIdartifactIdmybatis-spring-boot-starter/artifactId/dependency我们就会看到我们项目依赖中出现以groupIdartifactId命名的jar包了如下 对的通常第三方在写自动配置的时候命名风格皆是如此。而在里面的MybatisAutoConfiguration即为Mybatis的自动配置类。通过源码我们可以发现在里面注册了两个bean当然是有条件的 上面的意思是在Spring中如果没有SqlSessionFactory这个类型的bean则注册当前bean 另一个注册的bean如下 最核心的一个还是在自动配置类下面有一个这玩意 这个 Bean的作用是如果没有其他显式的注册Mapper扫描映射器那就注册一个默认的Mapper扫描映射器扫描路径跟SpringBoot扫描路径一致。说到这里是不是有朋友对Mybatis如何实现把接口转换成bean这个操作感兴趣呢大家伙可以看看按照下面这个轨迹从1-9-AB自上而下去看看但是需要一些Spring功底。源码入口MybatisAutoConfiguration.AutoConfiguredMapperScannerRegistrar#registerBeanDefinitions我有一点功底但不算很扎实 总的来说它的原大致如下注意这里是指默认自动配置类情况下如果使用了MapperScan注解情况略有不同
Mybatis自动配置类会向Spring容器注册一个扫描器Bean定义根据Bean定义初始化扫描器属性。默认扫描路径是当前SpringBoot的扫描路径Mybatis会修改扫描到Mapper接口的自动注入属性Mybatis会修改注册成为Bean的条件原本接口类是不能够被注册成为Bean的但是通过修改条件让其通过了判断具体怎么生成的Bean我还没去看…睡觉了
四、SpringBoot之AOP自动配置源码解析
未完待续…
五、SpringBoot Jar包启动过程源码解析
未完待续…
学习总结
感谢
感谢阿里云社区的文章《探索Spring Boot中的原则约定大于配置》 感谢百度大佬【作者编程师兄】的文章《SpringBoot约定大于配置到底是什么意思》
