第五十二章 Spring之再进一步—

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

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版）》

在之前的篇章中，A君已经把 MVC 也实现了，虽然没涉及到 WebFlux 这种异步操作的内容，但也把传统的 MVC 大体流程梳理了出来。现在 A君已经把 IOC、AOP、事务、MVC 都梳理过了。接下来，A君准备继续前行，开启新的篇章，也是这一系列的最后一部分内容——Boot篇

尝试动手写IOC容器

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

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

前情提要： A君在老大的指导下，先后完成了 IOC、AOP、事务、MVC 部分的内容。。。

迈入Boot阶段

完成 MVC 后，A君自以为功成事毕，可以闲暇一段时间了。可惜，理想很美好，现实很骨感。没过多久，A君就收到了老大的消息：来办公室下。“麻蛋，又有活了？”，看到信息，A君嘴里小声嘟囔着，不情不愿地起身往办公室走去

办公室内，只见老大盯着电脑屏幕，似乎在思考着什么。看到 A君过来了，老大笑了笑，指着旁边的小茶桌，说道：“坐吧，A君。我们来聊一聊后面的事吧！”

A君应了声，坐到椅子上。老大边烧着水，边说道：“A君，现在还需要一部分的内容。”

“现在 MVC 也完事了，难道 MVC 还需要新增内容吗？” A君问道

“MVC 部分就先这样吧，接下来我想跟你说的是 Boot 部分。” 老大一边沏茶，一边说道

“Boot？什么意思？” A君更加疑惑了

“在平时使用你自己开发的 MVC，或者说你做测试的时候，你觉得有什么不方便的地方吗？” 老大并没有直接回答，而是反问了 A君一下

A君思索了下，想到之前的种种，回答道：“额，如果一定要说的话，开发 Web 程序有点麻烦，既要配置XML，又得打成war包部署到Tomcat上，整个过程非常的繁琐！”

“是啊，还有依赖版本问题。你可曾想过这些东西是否可以进一步简化？” 老大又问道

“这不就是 SpringBoot 干的事吗？” A君疑惑道

“是的，SpringBoot 就是为了解决这些问题而出现的，软件行业一只在追求快速交付，从最开始的瀑布模型，再到现在的敏捷开发，整体的开发节奏都加快了，为了适应现在的蓬勃发展的快速应用开发领域（Rapid Application Development，RAD），我们也得跟进才行！” 老大茶也没心思喝了，语重心长的说道

“明白了，那我现在需要做什么呢？” 道理 A君自然是明白的，只是这活一直让 A君干，就很难受

“和之前一样，你先去调研、了解一下，后边做个小案例，我们到时候一起过一下。” 老大回道

“好吧！” A君应了一声之后，心里一阵诽谤：“丫的，茶没喝几口，事倒是接了不少。”

Boot的关键特性

大学时代，A君用的一直都是Eclipse+Tomcat+Spring，当时在开发的时候，不能说很麻烦，只能说是超级麻烦。一会Eclipse要配置Tomcat，一会儿又要配置XML，引了一堆jar包后，结果版本不兼容。好不容易开发完成之后，还要导出war部署到Tomcat上，大部分的时间都浪费在环境上了。不管是软件行业，还是人类社会，分工都是越来越细化。像 A君这样子的开发人员，其重心应该是放在业务代码开发上，而不是为了环境问题浪费大量时间。为此，当时初见 SpringBoot 时，着实给 A君带来极大的便利。为此，A君大致总结了 SpringBoot 的几个优势：

内嵌Tomcat，不需要war部署
约定大于配置，约定俗成的东西不需要额外的配置，自动配置
版本统一管理，简化Maven配置

这里就是 A君的个人的直观感受，啥八股文，啥专业名词。咱也不懂，就不班门弄斧了。既然功能点已经罗列出来了，还需要调研一下技术实现了

内嵌Tomcat

A君在之前整理 MVC 的时候就已经接触到了，Tomcat本身就已经提供了相应的依赖了，只需导入即可。为此，A君还是做了个小demo测试一下，首先需要引入相关依赖，pom.xml如下：

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.hqd</groupId>
  <artifactId>tomcat-jar-demo</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>

  <dependencies>
    <!-- Tomcat 8 嵌入式服务器 -->
    <dependency>
      <groupId>org.apache.tomcat.embed</groupId>
      <artifactId>tomcat-embed-core</artifactId>
      <version>8.5.73</version> <!-- 你可以选择你需要的版本 -->
    </dependency>
  </dependencies>
</project>

然后，在编写一个启动类，App类代码如下：

public class App {
    public static void main(String[] args) throws LifecycleException {
        Tomcat tomcat = new Tomcat();
        //设置端口
        tomcat.setPort(8082);
        //设置静态资源路径
        String webApp = new File("src/main/resources").getAbsolutePath();
        Context context = tomcat.addWebapp("/test/", webApp);
        tomcat.start();
        //挂起
        tomcat.getServer().await();
    }
}

这样就完事了，整体来说非常之简单，那么第一点也就解决了

自动装配

接下来的问题可就让 A君犯难了，自动配置，何为自动配置？简单思索了一阵后，A君对比了之前的实现。发现了一点端倪：按照之前的做法，配置bean的时候，需要声明对应的类，然后再配置属性，对应的bean才能被创建出来，实际上只要引入对应的依赖后，加上对应的配置，相关bean就能创建出来了，这样可以省去一堆配置，特别是像连接池、MQ等公共组件了。知道要做什么后，A君又被怎么做难住了。虽然这些可以自动装配，但是对应的bean有什么属性，怎么装配，这个框架是不可能知道的。那没办法了，只能依赖于强大的生态，让其他开源框架兼容进来，那现在的问题就变成了如何拿到其他框架自动配置的类了。嘿嘿，这个难不倒 A君，因为之前 A君已经有所了解了，那就是——SPI

SPI

要说到 SPI ，最经典的、接触最多的应该就是数据库驱动了，这应该是无人不知，无人不晓的东西了。老样子，A君先不管那些晦涩难懂的概念，就简单的问自己：为什么要怎么做？A君想了下，心中已经有了能说服自己的答案：毕竟 Java 本身只是定义规范，具体怎么实现是各个产商的事。那就有个问题了，JDK 本身只有接口，具体有哪个数据库，JDK 不可能提前知道的。那就继续定规范吧，于是，JDK 规定：类路径中的META-INF/services目录下配置服务提供者，程序可以在运行时动态加载这些服务实现类。如下：

在这里插入图片描述

既然大家都规定好了，那么 JDK 就有办法处理了，利用 JDK 提供的API就能找到对应的实现类了。例：

在这里插入图片描述

嘶，好像不太对劲。这么多中开源技术，怎么定义统一的接口？也不太可能每种技术都定义一个接口，这。。不好搞了，貌似刚想到的方案就要胎死腹中了。正所谓：山穷水尽疑无路，柳暗花明又一村。正在 A君一脸懵逼，不知所措的时候，忽然想到一件事：这可是 IOC容器 啊，都已经统一管理了，还怕区别不了配置类？完全模仿 SPI 的实现机制嘛！规定一个文件，里面可以配置需要自动配置的类，value不会怀疑，就是自动配置类的全路径，至于key嘛，就不用接口了，完全可以定义一个注解替代！例如：

在这里插入图片描述