第六十一章 Spring之假如让你来写Boot——番外篇：杂谈Starter-CSDN博客

本文链接：https://blog.csdn.net/weixin_42789334/article/details/146280130

Spring源码阅读目录

第一部分——IOC篇

第一章 Spring之最熟悉的陌生人——IOC
第二章 Spring之假如让你来写IOC容器——加载资源篇
第三章 Spring之假如让你来写IOC容器——解析配置文件篇
第四章 Spring之假如让你来写IOC容器——XML配置文件篇
第五章 Spring之假如让你来写IOC容器——BeanFactory和FactoryBean
第六章 Spring之假如让你来写IOC容器——Scope和属性填充
第七章 Spring之假如让你来写IOC容器——属性填充特别篇：SpEL表达式
第八章 Spring之假如让你来写IOC容器——拓展篇
第九章 Spring之源码阅读——环境搭建篇
第十章 Spring之源码阅读——IOC篇

第二部分——AOP篇

第三部分——事务篇

第二十五章 Spring之曾经的老朋友——事务
第二十六章 Spring之假如让你来写事务——初稿篇
第二十七章 Spring之假如让你来写事务——铁三角篇
第二十八章 Spring之假如让你来写事务——属性篇
第二十九章 Spring之假如让你来写事务——状态篇
第三十章 Spring之假如让你来写事务——管理篇
第三十一章 Spring之假如让你来写事务——融入IOC容器篇
第三十二章 Spring之源码阅读——事务篇

第四部分——MVC篇

第五部分——Boot篇

前言

对于Spring一直都是既熟悉又陌生，说对它熟悉吧，平时用用没啥问题，但面试的时候被问的一脸懵逼，就很尴尬，都不好意思在简历上写着熟悉Spring了
在这里插入图片描述

所以决定花点时间研究研究Spring的源码。主要参考的书籍是：《Spring源码深度解析（第2版）》、《Spring揭秘》、《Spring技术内幕：深入解析Spring架构与设计原理（第2版）》

书接上回，在上篇 第六十章 Spring之假如让你来写Boot——自动装配篇 中，A君昨天已经完成了自动装配这一大功能，自动装配可以说是 Boot 的半壁江山，剩下的东西也不多了。。。

尝试动手写IOC容器

出场人物：A君（苦逼的开发）、老大（项目经理）

背景：老大要求 A君在一周内开发个简单的 IOC容器

前情提要：A君已经完成了自动装配这一大功能。。。

杂谈Starter

前面 A君长篇大论解释了自动装配机制，不过呢，除了 SPI 机制之外，还有大名鼎鼎Starter，这个大家都耳熟能详的东西。接下来，A君就以国内大名鼎鼎的Druid连接池为例，详细了解下剩余的内容吧

什么是BOM？

不知道大家在平时开发中有没有遇到这样子的问题：

场景一：模块A需要添加个功能，这个由 A君进行开发，经过一阵分析后，A君决定引入c-1.0.jar。模块B也需要添加一个功能，由 B君开发，B君分析后，决定引入c-2.0.jar。这时候Maven就开始懵逼了，Maven表示很无奈，它只是个编译工具，也不知道到底以哪个版本为主，只能是先找到哪个就用哪个了

场景二：A君打算新建一个项目，这时候需要引入大量的jar包，分别引入了a-1.0.jar、b-2.0.jar。看着很正常吧，不过呢？假如a-1.0.jar也依赖b.jar，只是版本是1.0。嘿嘿，这时候就跟场景一的问题一模一样了

如果是场景一，大不了在群里大吼一声：到底是谁干的？场景二可没这么简单了，第三方jar包引起的版本问题更为隐蔽。Maven更无法自己解决了，工具解决不了，那问题就得落到人身上了，这时候开发也很难受，要知道因为jar包版本不统一引起的问题是没有道理可讲的，还经常折腾半天，解决了也没有任何成就感，简直就是开发中的‘毒瘤’。

既然存在问题，那就得想办法解决问题。现在jar版本问题搞得大家都难受，Maven就提出了一个解决方案——版本控制，也就是所谓的BOM。复杂的概念在这里就不说了，A君也不知道。还是一样的问题：如果让你来解决，你会怎么做？也好办，既然问题是由于不同人引入不同版本导致的，那就在一个地方统一导入就行了。在现在的开发中，每个项目一般都会有个父工程。父工程的pom.xml文件大体如下：

在这里插入图片描述
解决jar版本问题的奥秘就在dependencyManagement标签下。dependencyManagement下边规定了各个jar包的版本，它只定义了依赖的版本，不会自动引入这些依赖。子模块需要的话，直接根据groupId和artifactId引入就行了，不再需要带上版本，这样就能解决版本问题了。像这种专门用于管理jar包版本的就称作是BOM了。当然了，如果子模块还是需要使用不同于BOM中管理的版本时，依然可以在模块中显式指定版本号，从而覆盖BOM中的配置

啊，BOM虽然好，可是还是需要开发花大量的在版本管理上，而且还得知道各个jar包之间的依赖关系，这也太为难人了。那有没有办法让开发尽量少接触这些玩意。是的，又是那个男人站出来了。Spring 显然也考虑到了这点，所以它将大部分公共的jar包进行管理，起码和 Spring 版本是一一对应的，不会存在版本问题

在这里插入图片描述

如何定义一个Starter？

引入依赖

了解完BOM之后，再来看spring-boot-starter就很明了了。A君打开druid-spring-boot-starter.jar中的pom.xml。如下：

在这里插入图片描述
注意看，这个dependency很特殊哦，它的type不同于平时常见jar，而是pom类型。类型不一样，工作方式自然也就不同了。显然，这里是把 SpringBoot 的整个BOM导入进来了。除了这种方式外，还一种方式是继承，也就是parent标签：

在这里插入图片描述

这两种方式各有优缺点，大致如下：

parent：侧重于提供项目全局的配置和统一设置（包含依赖管理、插件、构建设置等），以单一继承方式传递给所有子模块

BOM：专门用于管理依赖版本，通过导入的方式将多个BOM的版本规则“组合”到项目中，解决了单继承带来的限制，同时仅用于版本控制，不影响其他构建配置。

parent的职能范围要大于BOM，在工作中，还是根据实际需要进行选择，没有最好只有最合适的

自动装配

导入弄清楚之后，接着 A君就直奔spring.factories 文件，这里是 SPI 的入口，必然指定了某个配置类。如下：

在这里插入图片描述

果然不出所料，这里指向了DruidDataSourceAutoConfigure，那就继续跟下去看看吧。代码如下：

在这里插入图片描述

看到这里，A君心里了然，都是老熟人了，全是之前了解过的东西了

为何IDEA中会有提示？

自动装配和版本管理，到这里 A君就彻底明白。不过，还有个小问题，A君有点好奇，就是平时在配置yaml文件的时候，会自动提示属性或者值，这又是怎么做到的？Spring 和 IDEA 之间，到底存在着什么py交易

在这里插入图片描述

为了满足自己的好奇心，A君又跑去druid-spring-boot-starter.jar底下翻找了起来。不出所料，在源码包里发现了一个奇怪的家伙

在这里插入图片描述
其他文件都好说，唯独这个json文件，新面孔。抱着试一试的心态，A君打开了他：

在这里插入图片描述

这就不奇怪了呀，明显是properties定义各个属性，并且用group进行分组。而hits则定义了properties的值

项目没用到的自动装配怎么办？

基于方便用户使用的角度，SpringBoot 尽量集成了市面上很多通用的框架，这也导致一个问题：在一个项目中，往往并不会用到那么多组件，这时候把这么多东西全部加载到内存，显然是不合适的，到时怕是32G内存都不够用了。所以为了我们的用户大大不骂娘，SpringBoot 同志还需多多努力才行。

到此为止，整个自动装配的逻辑 A君都弄明白了，再无秘密可言