SSM笔记（一）Spring基础

image-20221008182958877

Spring核心技术

前置课程要求： 请各位小伙伴先完成《JavaWeb》篇、《Java 9-17新特性》篇视频教程之后，再来观看此教程。

建议： 对Java开发还不是很熟悉的同学，最好先花费半个月到一个月时间大量地去编写小项目，不推荐一口气学完，后面的内容相比前面的内容几乎是降维打击，一口气学完很容易忘记之前所学的基础知识，尤其是JavaSE阶段的内容。

不同于2021版本SSM教程，本期视频为重制版本，视频学习的Spring框架版本为：6.0

恭喜各位顺利进入到SSM（Spring+SpringMVC+Mybatis）阶段的学习，也算是成功出了Java新手村，由于前面我们已经学习过Mybatis了，因此，本期教程的时间安排相比之前会更短一些。从这里开始，很多的概念理解起来就稍微有一点难度了，因为你们没有接触过企业开发场景，很难体会到那种思想带来的好处，甚至到后期接触到的几乎都是基于云计算和大数据理论实现的框架（当下最热门最前沿的技术）逐渐不再是和计算机基础相关联，而是和怎么高效干活相关了。

在JavaWeb阶段，我们已经学习了如何使用Java进行Web应用程序开发，我们现在已经具有搭建Web网站的能力，但是，我们在开发的过程中，发现存在诸多的不便，在最后的图书管理系统编程实战中，我们发现虽然我们思路很清晰，知道如何编写对应的接口，但是这样的开发效率，实在是太慢了，并且对于对象创建的管理，存在诸多的不妥之处，因此，我们要去继续学习更多的框架技术，来简化和规范我们的Java开发。

Spring就是这样的一个框架（文档：https://docs.spring.io/spring-framework/docs/6.0.10/reference/html/core.html#spring-core），它就是为了简化开发而生，它是轻量级的IoC和AOP的容器框架，主要是针对Bean的生命周期进行管理的轻量级容器，并且它的生态已经发展得极为庞大。那么，首先一问，什么是IoC和AOP，什么又是Bean呢？不要害怕，这些概念只是听起来满满的高级感，实际上没有多高级（很多东西都是这样，名字听起来很牛，实际上只是一个很容易理解的东西）

IoC容器基础

Spring框架最核心的其实它的IoC容器，这是我们开启Spring学习的第一站。

IoC理论介绍

在我们之前的图书管理系统Web应用程序中，我们发现，整个程序其实是依靠各个部分相互协作，共同完成一个操作，比如要展示借阅信息列表，那么首先需要使用Servlet进行请求和响应的数据处理，然后请求的数据全部交给对应的Service（业务层）来处理，当Service发现要从数据库中获取数据时，再向对应的Mapper发起请求。

它们之间就像连接在一起的齿轮，谁也离不开谁：

img

就像一个团队，每个人的分工都很明确，流水线上的一套操作必须环环相扣，这是一种高度耦合的体系。

虽然这样的体系逻辑非常清晰，整个流程也能够让人快速了解，但是这样存在一个很严重的问题，我们现在的时代实际上是一个软件项目高速迭代的时代，我们发现很多App三天两头隔三差五地就更新，而且是什么功能当下最火，就马不停蹄地进行跟进开发，因此，就很容易出现，之前写好的代码，实现的功能，需要全部推翻，改成新的功能，那么我们就不得不去修改某些流水线上的模块，但是这样一修改，会直接导致整个流水线的引用关系大面积更新。

比如下面的情况：

可以看到，A和C在大量地直接使用B，但是某一天，这个B的实现已经过时了，此时来了个把功能实现的更好的D，我们需要用这个新的类来完成业务了：

image-20221122135859871

可以看到，因为类之间的关联性太强了，会开始大面积报错，所有之前用了B的类，得挨个进行修改，全都改成D，这简直是灾难啊！

包括我们之前JavaWeb阶段编写的实战项目，如果我们不想用某个Service实现类了，我想使用其他的实现类用不同的逻辑做这些功能，那么这个时候，我们只能每个类都去挨个进行修改，当项目特别庞大时，光是改个类名导致的连带修改就够你改一天了。

因此，高耦合度带来的缺点是很明显的，也是现代软件开发中很致命的问题。如果要改善这种情况，我们只能将各个模块进行解耦，让各个模块之间的依赖性不再那么地强。也就是说，Service的实现类，不再由我们决定，而是让程序自己决定，所有的实现类对象，全部交给程序来管理，所有对象之间的关系，也由程序来动态决定，这样就引入了IoC理论。

IOC是Inversion of Control的缩写，翻译为：“控制反转”，把复杂系统分解成相互合作的对象，这些对象类通过封装以后，内部实现对外部是透明的，从而降低了解决问题的复杂度，而且可以灵活地被重用和扩展。

img

我们可以将对象交给IoC容器进行管理，比如当我们需要一个接口的实现时，由它根据配置文件来决定到底给我们哪一个实现类，这样，我们就可以不用再关心我们要去使用哪一个实现类了，我们只需要关心，给到我的一定是一个可以正常使用的实现类，能用就完事了，反正接口定义了啥，我只管调，这样，我们就可以放心地让一个人去写视图层的代码，一个人去写业务层的代码，开发效率那是高的一匹啊。

还是之前的代码，但是有了IoC容器加持之后：

当具体实现类发生修改时，我们同样只需要将新的实现类交给IoC容器管理，这样我们无需修改之前的任何代码：

这样，即使我们的底层实现类发生了修改，也不会导致与其相关联的类出现错误，而进行大面积修改，通过定义抽象+容器管理的形式，我们就可以将原有的强关联解除。

高内聚，低耦合，是现代软件的开发的设计目标，而Spring框架就给我们提供了这样的一个IoC容器进行对象的的管理，一个由Spring IoC容器实例化、组装和管理的对象，我们称其为Bean。

第一个Spring项目

首先一定要明确，使用Spring首要目的是为了使得软件项目进行解耦，而不是为了去简化代码！通过它，就可以更好的对我们的Bean进行管理，这一部分我们来体验一下Spring的基本使用。

Spring并不是一个独立的框架，它实际上包含了很多的模块：

image-20221121233807593

而我们首先要去学习的就是Core Container，也就是核心容器模块，只有了解了Spring的核心技术，我们才能真正认识这个框架为我们带来的便捷之处。

Spring是一个非入侵式的框架，就像一个工具库一样，它可以很简单地加入到我们已有的项目中，因此，我们只需要直接导入其依赖就可以使用了，Spring核心框架的Maven依赖坐标：

注意： 与旧版教程不同的是，Spring 6要求你使用的Java版本为17及以上，包括后面我们在学习SpringMvc时，要求Tomcat版本必须为10以上。这个依赖中包含了如下依赖：

image-20221122133820198

这里出现的都是Spring核心相关的内容，如Beans、Core、Context、SpEL以及非常关键的AOP框架，在本章中，我们都会进行讲解。

如果在使用Spring框架的过程中出现如下警告：
这是因为LocalVariableTableParameterNameDiscoverer在Spring 6.0.1版本已经被标记为过时，并且即将移除，请在Maven配置文件中为编译插件添加-parameters编译参数：
没有此问题请无视这部分。

这里我们就来尝试编写一个最简的Spring项目，我们在前面已经讲过了，Spring会给我们提供IoC容器用于管理Bean，但是我们得先为这个容器编写一个配置文件，我们可以通过配置文件告诉容器需要管理哪些Bean以及Bean的属性、依赖关系等等。

首先我们需要在resource中创建一个Spring配置文件（在resource中创建的文件，会在编译时被一起放到类路径下），命名为test.xml，直接右键点击即可创建：

此时IDEA会提示我们没有为此文件配置应用程序上下文，这里我们只需要指定成当前项目就行了，当然配置这个只是为了代码提示和依赖关系快速查看，如果不进行配置也不会影响什么，程序依然可以正常运行：

image-20221121234427739

这里我们直接按照默认配置点确定就行了：

image-20221121234447213

Spring为我们提供了一个IoC容器，用于去存放我们需要使用的对象，我们可以将对象交给IoC容器进行管理，当我们需要使用对象时，就可以向IoC容器去索要，并由它来决定给我们哪一个对象。而我们如果需要使用Spring为我们提供的IoC容器，那么就需要创建一个应用程序上下文，它代表的就是IoC容器，它会负责实例化、配置和组装Bean：

比如现在我们要让IoC容器帮助我们管理一个Student对象（Bean），当我们需要这个对象时再申请，那么就需要这样，首先先将Student类定义出来：

既然现在要让别人帮忙管理对象，那么就不能再由我们自己去new这个对象了，而是编写对应的配置，我们打开刚刚创建的test.xml文件进行编辑，添加：

这里我们就在配置文件中编写好了对应Bean的信息，之后容器就会根据这里的配置进行处理了。

现在，这个对象不需要我们再去创建了，而是由IoC容器自动进行创建并提供，我们可以直接从上下文中获取到它为我们创建的对象：

实际上，这里得到的Student对象是由Spring通过反射机制帮助我们创建的，初学者会非常疑惑，为什么要这样来创建对象，我们直接new一个它不香吗？为什么要交给IoC容器管理呢？在后面的学习中，我们再慢慢进行体会。

image-20221122153946251

Bean注册与配置

前面我们通过一个简单例子体验了一下如何使用Spring来管理我们的对象，并向IoC容器索要被管理的对象。这节课我们就来详细了解一下如何向Spring注册Bean以及Bean的相关配置。

实际上我们的配置文件可以有很多个，并且这些配置文件是可以相互导入的：

但是为了简单起见，我们还是从单配置文件开始讲起，首先我们需要知道如何配置Bean并注册。

要配置一个Bean，只需要添加：

但是这样写的话，Spring无法得知我们要配置的Bean到底是哪一个类，所以说我们还得指定对应的类才可以：

image-20221122164149924

可以看到类的旁边出现了Bean的图标，表示我们的Bean已经注册成功了，这样，我们就可以根据类型向容器索要Bean实例对象了：

不过在有些时候，Bean的获取可能会出现歧义，我们可以来分别注册两个子类的Bean：

但是此时我们在获取Bean时却是索要的它们的父类：

运行时得到如下报错：

image-20221122164100561

这里出现了一个Bean定义不唯一异常，很明显，因为我们需要的类型是Student，但是此时有两个Bean定义都满足这个类型，它们都是Student的子类，此时IoC容器不知道给我们返回哪一个Bean，所以就只能抛出异常了。

因此，如果我们需要一个Bean并且使用类型进行获取，那么必须要指明类型并且不能出现歧义：

那要是两个Bean的类型都是一样的呢？

这种情况下，就无法使用Class来进行区分了，除了为Bean指定对应类型之外，我们也可以为Bean指定一个名称用于区分：

name属性就是为这个Bean设定一个独一无二的名称（id属性也可以，跟name功能相同，但是会检查命名是否规范，否则会显示黄标），不同的Bean名字不能相同，否则报错：

这样，这两个Bean我们就可以区分出来了：

虽然目前这两Bean定义都是一模一样的，也没什么区别，但是这确实是两个不同的Bean，只是类型一样而已，之后我们还可以为这两个Bean分别设置不同的其他属性。

我们可以给Bean起名字，也可以起别名，就行我们除了有一个名字之外，可能在家里还有自己的小名：

这样，我们使用别名也是可以拿到对应的Bean的：

那么现在又有新的问题了，IoC容器创建的Bean是只有一个还是每次索要的时候都会给我们一个新的对象？我们现在在主方法中连续获取两次Bean对象：

我们发现，最后得到的结果为true，那么说明每次从IoC容器获取到的对象，始终都是同一个，默认情况下，通过IoC容器进行管理的Bean都是单例模式的，这个对象只会被创建一次。

如果我们希望每次拿到的对象都是一个新的，我们也可以将其作用域进行修改：

image-20221122175719997

这里一共有两种作用域，第一种是singleton，默认情况下就是这一种，当然还有prototype，表示为原型模式（为了方便叫多例模式也行）这种模式每次得到的对象都是一个新的：

实际上，当Bean的作用域为单例模式时，那么它会在一开始（容器加载配置时）就被创建，我们之后拿到的都是这个对象。而处于原型模式下，只有在获取时才会被创建，也就是说，单例模式下，Bean会被IoC容器存储，只要容器没有被销毁，那么此对象将一直存在，而原型模式才是相当于在要用的时候直接new了一个对象，并不会被保存。

当然，如果我们希望单例模式下的Bean不用再一开始就加载，而是一样等到需要时再加载（加载后依然会被容器存储，之后一直使用这个对象了，不会再创建新的）我们也可以开启懒加载：

开启懒加载后，只有在真正第一次使用时才会创建对象。

因为单例模式下Bean是由IoC容器加载，但是加载顺序我们并不清楚，如果我们需要维护Bean的加载顺序（比如某个Bean必须要在另一个Bean之前创建）那么我们可以使用depends-on来设定前置加载Bean，这样被依赖的Bean一定会在之前加载，比如Teacher应该在Student之前加载：

这样就可以保证Bean的加载顺序了。

依赖注入

依赖注入(Dependency Injection, DI)是一种设计模式，也是Spring框架的核心概念之一。现在我们已经了解了如何注册和使用一个Bean，但是这样还远远不够，还记得我们一开始说的，消除类之间的强关联吗？比如现在有一个教师接口：

具体的实现有两个：

我们的学生一开始有一个老师教他，比如美术老师：

但是我们发现，如果美术老师不教了，现在来了一个其他的老师教学生，那么就需要去修改Student类的定义：

可以想象一下，如果现在冒出来各种各样的类都需要这样去用Teacher，那么一旦Teacher的实现发生变化，会导致我们挨个对之前用到Teacher的类进行修改，这就很难受了。

而有了依赖注入之后，Student中的Teacher成员变量，可以由IoC容器来选择一个合适的Teacher对象进行赋值，也就是说，IoC容器在创建对象时，需要将我们预先给定的属性注入到对象中，非常简单，我们可以使用property标签来实现，我们将bean标签展开：

同时我们还需要修改一下Student类，依赖注入要求对应的属性必须有一个set方法：

image-20221122191025279

使用property来指定需要注入的值或是一个Bean，这里我们选择ProgramTeacher，那么在使用时，Student类中的得到的就是这个Bean的对象了：

image-20221122191109690

可以看到，现在我们的Java代码中，没有出现任何的具体实现类信息（ArtTeacher、ProgramTeacher都没出现）取而代之的是那一堆xml配置，这样，就算我们切换老师的实现为另一个类，也不用去调整代码，只需要变动一下Bean的类型就可以：

这样，这个Bean的class就变成了新的类型，并且我们不需要再去调整其他位置的代码，再次启动程序：

image-20221122191427776

通过依赖注入，是不是开始逐渐感受到Spring为我们带来的便利了？当然，依赖注入并不一定要注入其他的Bean，也可以是一个简单的值：

直接使用value可以直接传入一个具体值。

实际上，在很多情况下，类中的某些参数是在构造方法中就已经完成的初始化，而不是创建之后，比如：

我们前面说了，Bean实际上是由IoC容器进行创建的，但是现在我们修改了默认的无参构造，可以看到配置文件里面报错了：

image-20221122174328107

很明显，是因为我们修改了构造方法，IoC容器默认只会调用无参构造，所以，我们需要指明一个可以用的构造方法，我们展开bean标签，添加一个constructor-arg标签：

这里的constructor-arg就是构造方法的一个参数，这个参数可以写很多个，会自动匹配符合里面参数数量的构造方法，这里匹配的就是我们刚刚编写的需要一个参数的构造方法。

image-20221122191427776

通过这种方式，我们也能实现依赖注入，只不过现在我们将依赖注入的时机提前到了对象构造时。

那要是出现这种情况呢？现在我们的Student类中是这样定义的：

此时我们希望使用的是二号构造方法，那么怎么才能指定呢？有2种方式，我们可以给标签添加类型：

也可以指定为对应的参数名称：

反正只要能够保证我们指定的参数匹配到目标构造方法即可。

现在我们的类中出现了一个比较特殊的类型，它是一个集合类型：

对于这种集合类型，有着特殊的支持：

不仅仅是List，Map、Set这类常用集合类包括数组在内，都是支持这样编写的，比如Map类型，我们也可以使用entry来注入：

至此，我们就已经完成了两种依赖注入的学习：

Setter依赖注入：通过成员属性对应的set方法完成注入。

构造方法依赖注入：通过构造方法完成注入。

自动装配

在之前，如果我们需要使用依赖注入的话，我们需要对property参数进行配置：

但是有些时候为了方便，我们也可以开启自动装配。自动装配就是让IoC容器自己去寻找需要填入的值，我们只需要将set方法提供好就可以了，这里需要添加autowire属性：

autowire属性有两个值普通，一个是byName，还有一个是byType，顾名思义，一个是根据类型去寻找合适的Bean自动装配，还有一个是根据名字去找，这样我们就不需要显式指定property了。

image-20221122221936559

此时set方法旁边会出现一个自动装配图标，效果和上面是一样的。

对于使用构造方法完成的依赖注入，也支持自动装配，我们只需要将autowire修改为：

这样，我们只需要提供一个对应参数的构造方法就可以了（这种情况默认也是byType寻找的）：

image-20221122230320004

这样同样可以完成自动注入：

image-20221122191427776

自动化的东西虽然省事，但是太过机械，有些时候，自动装配可能会遇到一些问题，比如出现了下面的情况：

image-20221122223048820

此时，由于autowire的规则为byType，存在两个候选Bean，但是我们其实希望ProgramTeacher这个Bean在任何情况下都不参与到自动装配中，此时我们就可以将它的自动装配候选关闭：

当autowire-candidate设定false时，这个Bean将不再作为自动装配的候选Bean，此时自动装配候选就只剩下一个唯一的Bean了，报错消失，程序可以正常运行。

除了这种方式，我们也可以设定primary属性，表示这个Bean作为主要的Bean，当出现歧义时，也会优先选择：

这样写程序依然可以正常运行，并且选择的也是ArtTeacher（就是不知道为什么IDEA会上红标，BUG？）

生命周期与继承

除了修改构造方法，我们也可以为Bean指定初始化方法和销毁方法，以便在对象创建和被销毁时执行一些其他的任务：

我们可以通过init-method和destroy-method来指定：

那么什么时候是初始化，什么时候又是销毁呢？

所以说，最后的结果为：

image-20221123132604262

注意，如果Bean不是单例模式，而是采用的原型模式，那么就只会在获取时才创建，并调用init-method，而对应的销毁方法不会被调用（因此，对于原型模式下的Bean，Spring无法顾及其完整生命周期，而在单例模式下，Spring能够从Bean对象的创建一直管理到对象的销毁）官方文档原文如下：

In contrast to the other scopes, Spring does not manage the complete lifecycle of a prototype bean. The container instantiates, configures, and otherwise assembles a prototype object and hands it to the client, with no further record of that prototype instance. Thus, although initialization lifecycle callback methods are called on all objects regardless of scope, in the case of prototypes, configured destruction lifecycle callbacks are not called. The client code must clean up prototype-scoped objects and release expensive resources that the prototype beans hold. To get the Spring container to release resources held by prototype-scoped beans, try using a custom bean post-processor, which holds a reference to beans that need to be cleaned up.

Bean之间也是具备继承关系的，只不过这里的继承并不是类的继承，而是属性的继承，比如：

此时，我们先将ArtStudent注册一个Bean：

这里我们会注入一个name的初始值，此时我们创建了一个SportStudent的Bean，我们希望这个Bean的属性跟刚刚创建的Bean属性是一样的，那么我们可以写一个一模一样的：

但是如果属性太多的话，是不是写起来有点麻烦？这种情况，我们就可以配置Bean之间的继承关系了，我们可以让SportStudent这个Bean直接继承ArtStudent这个Bean配置的属性：

这样，在ArtStudent Bean中配置的属性，会直接继承给SportStudent Bean（注意，所有配置的属性，在子Bean中必须也要存在，并且可以进行注入，否则会出现错误）当然，如果子类中某些属性比较特殊，也可以在继承的基础上单独配置：

如果我们只是希望某一个Bean仅作为一个配置模版供其他Bean继承使用，那么我们可以将其配置为abstract，这样，容器就不会创建这个Bean的对象了：

注意，一旦声明为抽象Bean，那么就无法通过容器获取到其实例化对象了。

image-20221123140409416

不过Bean的继承使用频率不是很高，了解就行。

这里最后再提一下，我们前面已经学习了各种各样的Bean配置属性，如果我们希望整个上下文中所有的Bean都采用某种配置，我们可以在最外层的beans标签中进行默认配置：

image-20221123141221259

这样，即使Bean没有配置某项属性，但是只要在最外层编写了默认配置，那么同样会生效，除非Bean自己进行配置覆盖掉默认配置。

工厂模式和工厂Bean

前面我们介绍了IoC容器的Bean创建机制，默认情况下，容器会调用Bean对应类型的构造方法进行对象创建，但是在某些时候，我们可能不希望外界使用类的构造方法完成对象创建，比如在工厂方法设计模式中（详情请观看《Java设计模式》篇视频教程）我们更希望 Spring不要直接利用反射机制通过构造方法创建Bean对象，而是利用反射机制先找到对应的工厂类，然后利用工厂类去生成需要的Bean对象：

此时Student有一个工厂，我们正常情况下需要使用工厂才可以得到Student对象，现在我们希望Spring也这样做，不要直接去反射搞构造方法创建，我们可以通过factory-method进行指定：

注意，这里的Bean类型需要填写为Student类的工厂类，并且添加factory-method指定对应的工厂方法，但是最后注册的是工厂方法的返回类型，所以说依然是Student的Bean：

image-20221123143302785

此时我们再去进行获取，拿到的也是通过工厂方法得到的对象：

image-20221123143347376

这里有一个误区，千万不要认为是我们注册了StudentFactory这个Bean，class填写为这个类这个只是为了告诉Spring我们的工厂方法在哪个位置，真正注册的是工厂方法提供的东西。

可以发现，当我们采用工厂模式后，我们就无法再通过配置文件对Bean进行依赖注入等操作了，而是只能在工厂方法中完成，这似乎与Spring的设计理念背道而驰？

当然，可能某些工厂类需要构造出对象之后才能使用，我们也可以将某个工厂类直接注册为工厂Bean：

现在需要StudentFactory对象才可以获取到Student，此时我们就只能先将其注册为Bean了：

像这样将工厂类注册为Bean，我们称其为工厂Bean，然后再使用factory-bean来指定Bean的工厂Bean：

注意，使用factory-bean之后，不再要求指定class，我们可以直接使用了：

image-20221123164134470

此时可以看到，工厂方法上同样有了图标，这种方式，由于工厂类被注册为Bean，此时我们就可以在配置文件中为工厂Bean配置依赖注入等内容了。

这里还有一个很细节的操作，如果我们想获取工厂Bean为我们提供的Bean，可以直接输入工厂Bean的名称，这样不会得到工厂Bean的实例，而是工厂Bean生产的Bean的实例：

当然，如果我们需要获取工厂类的实例，可以在名称前面添加&符号：

又是一个小细节。

使用注解开发

前面我们已经完成了大部分的配置文件学习，但是我们发现，使用配置文件进行配置，貌似有点太累了吧？可以想象一下，如果我们的项目非常庞大，整个配置文件将会充满Bean配置，并且会继续庞大下去，能否有一种更加高效的方法能够省去配置呢？还记得我们在JavaWeb阶段用到的非常方便东西吗？没错，就是注解。

既然现在要使用注解来进行开发，那么我们就删掉之前的xml配置文件吧，我们来看看使用注解能有多方便。

现在我们使用AnnotationConfigApplicationContext作为上下文实现，它是注解配置的。

既然现在采用注解，我们就需要使用类来编写配置文件，在之前，我们如果要编写一个配置的话，需要：

现在我们只需要创建一个配置类就可以了：

这两者是等价的，同样的，在一开始会提示我们没有配置上下文：

image-20221123175555433

这里按照要求配置一下就可以，同上，这个只是会影响IDEA的代码提示，不会影响程序运行。

我们可以为AnnotationConfigApplicationContext指定一个默认的配置类：

那么现在我们该如何配置Bean呢？

这样写相对于配置文件中的：

通过@Import还可以引入其他配置类：

只不过现在变成了由Java代码为我们提供Bean配置，这样会更加的灵活，也更加便于控制Bean对象的创建。

使用方法是相同的，这跟使用XML配置是一样的。

那么肯定就有小伙伴好奇了，我们之前使用的那么多特性在哪里配置呢？首先，初始化方法和摧毁方法、自动装配可以直接在@Bean注解中进行配置：

其次，我们可以使用一些其他的注解来配置其他属性，比如：

对于那些我们需要通过构造方法或是Setter完成依赖注入的Bean，比如：

像这种需要引入其他Bean进行的注入，我们可以直接将其作为形式参数放到方法中：

此时我们可以看到，旁边已经出现图标了：

image-20221123213527325

运行程序之后，我们发现，这样确实可以直接得到对应的Bean并使用。

只不过，除了这种基于构造器或是Setter的依赖注入之外，我们也可以直接到Bean对应的类中使用自动装配：

现在，我们甚至连构造方法和Setter都不需要去编写了，就能直接完成自动装配，是不是感觉比那堆配置方便多了？

当然，@Autowired并不是只能用于字段，对于构造方法或是Setter，它同样可以：

@Autowired默认采用byType的方式进行自动装配，也就是说会使用类型进行配，那么要是出现了多个相同类型的Bean，如果我们想要指定使用其中的某一个该怎么办呢？

此时，我们可以配合@Qualifier进行名称匹配：

这里需要提一下，在我们旧版本的SSM教程中讲解了@Resource这个注解，但是现在它没有了。

随着Java版本的更新迭代，某些javax包下的包，会被逐渐弃用并移除。在JDK11版本以后，javax.annotation这个包被移除并且更名为jakarta.annotation（我们在JavaWeb篇已经介绍过为什么要改名字了）其中有一个非常重要的注解，叫做@Resource，它的作用与@Autowired时相同的，也可以实现自动装配，但是在IDEA中并不推荐使用@Autowired注解对成员字段进行自动装配，而是推荐使用@Resource，如果需要使用这个注解，还需要额外导入包：

使用方法一样，直接替换掉就可以了：

只不过，他们两有些机制上的不同：

@Resource默认ByName如果找不到则ByType，可以添加到set方法、字段上。

@Autowired默认是byType，只会根据类型寻找，可以添加在构造方法、set方法、字段、方法参数上。

因为@Resource的匹配机制更加合理高效，因此官方并不推荐使用@Autowired字段注入，当然，实际上Spring官方更推荐我们使用基于构造方法或是Setter的@Autowired注入，比如Setter 注入的一个好处是，Setter 方法使该类的对象能够在以后重新配置或重新注入。其实，最后使用哪个注解，还是看你自己，要是有强迫症不能忍受黄标但是又实在想用字段注入，那就用@Resource注解。

除了这个注解之外，还有@PostConstruct和@PreDestroy，它们效果和init-method和destroy-method是一样的：

我们只需要将其添加到对应的方法上即可：

image-20221123225232979

可以看到效果是完全一样的，这些注解都是jakarta.annotation提供的，有关Spring和JakartaEE的渊源，还请各位小伙伴自行了解。

前面我们介绍了使用@Bean来注册Bean，但是实际上我们发现，如果只是简单将一个类作为Bean的话，这样写还是不太方便，因为都是固定模式，就是单纯的new一个对象出来，能不能像之前一样，让容器自己反射获取构造方法去生成这个对象呢？

肯定是可以的，我们可以在需要注册为Bean的类上添加@Component注解来将一个类进行注册（现在最常用的方式），不过要实现这样的方式，我们需要添加一个自动扫描来告诉Spring，它需要在哪些包中查找我们提供的@Component声明的Bean。

要注册这个类的Bean，只需要添加@Component即可，然后配置一下包扫描：

Spring在扫描对应包下所有的类时，会自动将那些添加了@Component的类注册为Bean，是不是感觉很方便？只不过这种方式只适用于我们自己编写类的情况，如果是第三方包提供的类，只能使用前者完成注册，并且这种方式并不是那么的灵活。

不过，无论是通过@Bean还是@Component形式注册的Bean，Spring都会为其添加一个默认的name属性，比如：

它的默认名称生产规则依然是类名并按照首字母小写的驼峰命名法来的，所以说对应的就是student：

同样的，如果是通过@Bean注册的，默认名称是对应的方法名称：

相比传统的XML配置方式，注解形式的配置确实能够减少我们很多工作量。并且，对于这种使用@Component注册的Bean，如果其构造方法不是默认无参构造，那么默认会对其每一个参数都进行自动注入：

最后，对于我们之前使用的工厂模式，Spring也提供了接口，我们可以直接实现接口表示这个Bean是一个工厂Bean：

实际上跟我们之前在配置文件中编写是一样的，这里就不多说了。

请注意，使用注解虽然可以省事很多，代码也能变得更简洁，但是这并不代表XML配置文件就是没有意义的，它们有着各自的优点，在不同的场景下合理使用，能够起到事半功倍的效果，官方原文：

Are annotations better than XML for configuring Spring?
The introduction of annotation-based configuration raised the question of whether this approach is “better” than XML. The short answer is “it depends.” The long answer is that each approach has its pros and cons, and, usually, it is up to the developer to decide which strategy suits them better. Due to the way they are defined, annotations provide a lot of context in their declaration, leading to shorter and more concise configuration. However, XML excels at wiring up components without touching their source code or recompiling them. Some developers prefer having the wiring close to the source while others argue that annotated classes are no longer POJOs and, furthermore, that the configuration becomes decentralized and harder to control.
No matter the choice, Spring can accommodate both styles and even mix them together. It is worth pointing out that through its JavaConfig option, Spring lets annotations be used in a non-invasive way, without touching the target components source code and that, in terms of tooling, all configuration styles are supported by the Spring Tools for Eclipse.

至此，关于Spring的IoC基础部分，我们就全部介绍完了。在最后，留给各位小伙伴一个问题，现在有两个类：

这两个类互相需要注入对方的实例对象，这个时候Spring会怎么进行处理呢？如果Bean变成原型模式，Spring又会怎么处理呢？

这个问题我们会在实现原理探究部分进行详细介绍。

Spring高级特性（选学）

注意： 本部分为选学内容，如果Spring基础部分学的不是很明白，不建议看这一部分，在理解清楚之后再来看也可以，但也不是说以后就不用学了，这些东西在某些项目中可能会用到，你迟早还是要回来补的。

前面我们介绍了Spring的基础部分，我们接着来介绍Spring的一些其他高级特性。

Bean Aware

在Spring中提供了一些以Aware结尾的接口，实现了Aware接口的bean在被初始化之后，可以获取相应资源。Aware的中文意思为感知。简单来说，他就是一个标识，实现此接口的类会获得某些感知能力，Spring容器会在Bean被加载时，根据类实现的感知接口，会调用类中实现的对应感知方法。

比如BeanNameAware之类的以Aware结尾的接口，这个接口获取的资源就是BeanName：

又比如BeanClassLoaderAware，那么它能够使得我们可以在Bean加载阶段就获取到当前Bean的类加载器：

有关其他的Aware这里就不一一列举了，我们会在后面的实现原理探究部分逐步认识的。

任务调度

为了执行某些任务，我们可能需要一些非常规的操作，比如我们希望使用多线程来处理我们的结果或是执行一些定时任务，到达指定时间再去执行。这时我们首先想到的就是创建一个新的线程来处理，或是使用TimerTask来完成定时任务，但是我们有了Spring框架之后，就不用这样了，因为Spring框架为我们提供了更加便捷的方式进行任务调度。

首先我们来看异步任务执行，需要使用Spring异步任务支持，我们需要在配置类上添加@EnableAsync注解。

接着我们只需要在需要异步执行的方法上，添加@Async注解即可将此方法标记为异步，当此方法被调用时，会异步执行，也就是新开一个线程执行，而不是在当前线程执行。我们来测试一下：

现在我们在主方法中分别调用一下试试看：

可以看到，我们的任务执行结果为：

image-20221125153110860

很明显，异步执行的任务并不是在当前线程启动的，而是在其他线程启动的，所以说并不会在当前线程阻塞，可以看到马上就开始执行下一行代码，调用同步执行的任务了。

因此，当我们要将Bean的某个方法设计为异步执行时，就可以直接添加这个注解。但是需要注意，添加此注解要求方法的返回值只能是void或是Future类型才可以（Future类型我们在JUC篇视频教程中有详细介绍）

还有，在使用时，可能还会出现这样的信息：

image-20221125153426124

虽然出现了这样的信息，但是我们的程序依然可以正常运行，这是因为Spring默认会从容器中选择一个Executor类型（这同样是在JUC篇视频教程中介绍的类型）的实例，并使用它来创建线程执行任务，这是Spring推荐的方式，当然，如果没有找到，那么会使用自带的 SimpleAsyncTaskExecutor 处理异步方法调用。

肯定会有小伙伴疑惑，什么情况？！这个方法很明显我们并没有去编写异步执行的逻辑，那么为什么会异步执行呢？这里很明显是同步调用的方法啊。的确，如果这个Bean只是一个简简单单的Student类型的对象，确实做不到。但是它真的只是一个简简单单的Student类型对象吗？

我们来看看结果：

image-20221125154133618

？？？这是什么东西？这实际上Spring帮助我们动态生成的一个代理类，我们原本的类代码已经被修改了，当然，这只是冰山一角，更多的内容，我们还会再AOP面向切片部分中继续为大家进行介绍，能做到这样的操作，这其实都是AOP的功劳。

看完了异步任务，我们接着来看定时任务，定时任务其实就是指定在哪个时候再去执行，在JavaSE阶段我们使用过TimerTask来执行定时任务。Spring中的定时任务是全局性质的，当我们的Spring程序启动后，那么定时任务也就跟着启动了，我们可以在配置类上添加@EnableScheduling注解：

接着我们可以直接在配置类里面编写定时任务，把我们要做的任务写成方法，并添加@Scheduled注解：

image-20221125155352390

我们注意到@Scheduled中有很多参数，我们需要指定’cron’, ‘fixedDelay(String)’, or ’fixedRate(String)’的其中一个，否则无法创建定时任务，他们的区别如下：

fixedDelay：在上一次定时任务执行完之后，间隔多久继续执行。

fixedRate：无论上一次定时任务有没有执行完成，两次任务之间的时间间隔。

cron：如果嫌上面两个不够灵活，你还可以使用cron表达式来指定任务计划。

这里简单讲解一下cron表达式：https://blog.csdn.net/sunnyzyq/article/details/98597252

监听器

监听器对我们来说也是一个比较陌生的概念，那么何谓监听呢？

监听实际上就是等待某个事件的触发，当事件触发时，对应事件的监听器就会被通知，如果你学习过Java Swing篇视频教程，应该会深有体会，监听器可是很关键的，只不过在Spring中用的不是很频繁罢了。但是这里还是要简单介绍一下：

要编写监听器，我们只需要让Bean继承ApplicationListener就可以了，并且将类型指定为对应的Event事件，这样，当发生某个事件时就会通知我们，比如ContextRefreshedEvent，这个事件会在Spring容器初始化完成会触发一次：

image-20221125155804255

是不是感觉挺智能的？Spring内部有各种各样的事件，当然我们也可以自己编写事件，然后在某个时刻发布这个事件到所有的监听器：

比如现在我们希望在定时任务中每秒钟发生一次这个事件：

此时，发布事件旁边出现了图标，说明就可以了：

image-20221125161224037

我们可以点击这个图标快速跳转到哪里监听了这个事件，IDEA这些细节做的还是挺好的。我们来看看运行结果吧：

image-20221125161125557

是不是感觉好像也没那么难，这套机制其实还挺简单的，这样，我们就实现了自定义事件发布和监听。

SpringEL表达式

SpEL 是一种强大，简洁的装配 Bean 的方式，它可以通过运行期间执行的表达式将值装配到我们的属性或构造函数当中，更可以调用 JDK 中提供的静态常量，获取外部 Properties 文件中的的配置。

外部属性注入

有些时候，我们甚至可以将一些外部配置文件中的配置进行读取，并完成注入。

我们需要创建以.properties结尾的配置文件，这种配置文件格式很简单，类似于Map，需要一个Key和一个Value，中间使用等号进行连接，这里我们在resource目录下创建一个test.properties文件：

这样，Key就是test.name，Value就是只因，我们可以通过一个注解直接读取到外部配置文件中对应的属性值，首先我们需要引入这个配置文件，我们可以在配置类上添加@PropertySource注解：

接着，我们就可以开始快乐的使用了，我们可以使用 @Value 注解将外部配置文件中的值注入到任何我们想要的位置，就像我们之前使用@Resource自动注入一样：

@Value中的${...}表示占位符，它会读取外部配置文件的属性值装配到属性中，如果配置正确没问题的话，这里甚至还会直接显示对应配置项的值：

image-20221125164854022

我们来测试一下吧：

image-20221125165145332

如果遇到乱码的情况，请将配置文件的编码格式切换成UTF-8（可以在IDEA设置中进行配置）然后在@PropertySource注解中添加属性 encoding = “UTF-8” 这样就正常了，当然，其实一般情况下也很少会在配置文件中用到中文。

除了在字段上进行注入之外，我们也可以在需要注入的方法中使用：

当然，如果我们只是想简单的注入一个常量值，也可以直接填入固定值：

当然，@Value 的功能还远不止这些，配合SpringEL表达式，能够实现更加强大的功能。

SpEL简单使用

Spring官方为我们提供了一套非常高级SpEL表达式，通过使用表达式，我们可以更加灵活地使用Spring框架。

首先我们来看看如何创建一个SpEL表达式：

这里得到的就是一个很简单的 Hello World 字符串，字符串使用单引号囊括，SpEL是具有运算能力的。

我们可以像写Java一样，对这个字符串进行各种操作，比如调用方法之类的：

image-20221125173157008

不仅能调用方法、还可以访问属性、使用构造方法等，是不是感觉挺牛的，居然还能这样玩。

对于Getter方法，我们可以像访问属性一样去使用：

表达式可以不止一级，我们可以多级调用：

是不是感觉挺好玩的？我们继续来试试看构造方法，其实就是写Java代码，只是可以写成这种表达式而已：

image-20221125173157008

它甚至还支持根据特定表达式，从给定对象中获取属性出来：

拿到对象属性之后，甚至还可以继续去处理：

除了获取，我们也可以调用表达式的setValue方法来设定属性的值：

除了属性调用，我们也可以使用运算符进行各种高级运算：

对于那些需要导入才能使用的类，我们需要使用一个特殊的语法：

集合操作相关语法

现在我们的类中存在一些集合类：

我们可以使用SpEL快速取出集合中的元素：

我们也可以快速创建集合：

你以为就这么简单吗，我们还可以直接根据条件获取集合中的元素：

我们还可以针对某个属性创建对应的投影集合：

image-20221130153142677

我们接着来介绍安全导航运算符，安全导航运算符用于避免NullPointerException，它来自Groovy语言。通常，当您有对对象的引用时，您可能需要在访问对象的方法或属性之前验证它是否为空。为了避免这种情况，安全导航运算符返回null而不是抛出异常。以下示例显示了如何使用安全导航运算符：

image-20221130150723018

当遇到null时很不方便，我们还得写判断：

Java 8之后能这样写：

但是你如果写过Kotlin：

类似于这种判空问题，我们就可以直接使用安全导航运算符，SpEL也支持这种写法：

当遇到空时，只会得到一个null，而不是直接抛出一个异常：

image-20221130150654287

我们可以将SpEL配合 @Value 注解或是xml配置文件中的value属性使用，比如XML中可以这样写：

或是使用注解开发：

这样，我们有时候在使用配置文件中的值时，就能进行一些简单的处理了。

有关更多详细语法教程，请前往：https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#expressions-language-ref

AOP面向切片

又是一个听起来很高大上的名词，AOP（Aspect Oriented Programming）思想实际上就是：在运行时，动态地将代码切入到类的指定方法、指定位置上。也就是说，我们可以使用AOP来帮助我们在方法执行前或执行之后，做一些额外的操作，实际上，它就是代理！

通过AOP我们可以在保证原有业务不变的情况下，添加额外的动作，比如我们的某些方法执行完成之后，需要打印日志，那么这个时候，我们就可以使用AOP来帮助我们完成，它可以批量地为这些方法添加动作。可以说，它相当于将我们原有的方法，在不改变源代码的基础上进行了增强处理。

image-20221130155358974

相当于我们的整个业务流程，被直接斩断，并在断掉的位置添加了一个额外的操作，再连接起来，也就是在一个切点位置插入内容。它的原理实际上就是通过动态代理机制实现的，我们在JavaWeb阶段已经给大家讲解过动态代理了。不过Spring底层并不是使用的JDK提供的动态代理，而是使用的第三方库实现，它能够以父类的形式代理，而不仅仅是接口。

使用配置实现AOP

在开始之前，我们先换回之前的XML配置模式，之后也会给大家讲解如何使用注解完成AOP操作，注意这里我们还加入了一些新的AOP相关的约束进来，建议直接CV下面的：

Spring是支持AOP编程的框架之一（实际上它整合了AspectJ框架的一部分），要使用AOP我们需要先导入一个依赖：

那么，如何使用AOP呢？首先我们要明确，要实现AOP操作，我们需要知道这些内容：

需要切入的类，类的哪个方法需要被切入

切入之后需要执行什么动作

是在方法执行前切入还是在方法执行后切入

如何告诉Spring需要进行切入

比如现在我们希望对这个学生对象的study方法进行增强，在不修改源代码的情况下，增加一些额外的操作：

那么我们按照上面的流程，依次来看，首先需要解决的问题是，找到需要切入的类，很明显，就是这个Student类，我们要切入的是这个study方法。

第二步，我们切入之后要做什么呢？这里我们直接创建一个新的类，并将要执行的操作写成一个方法：

注意这个类也得注册为Bean才可以：

第三步，我们要明确这是在方法执行之前切入还是执行之后切入，很明显，按照上面的要求，我们需要执行之后进行切入。

第四步，最关键的来了，我们怎么才能告诉Spring我们要进行切入操作呢？这里我们需要在配置文件中进行AOP配置：

接着我们需要添加一个新的切点，首先填写ID，这个随便起都可以：

然后就是通过后面的expression表达式来选择到我们需要切入的方法，这个表达式支持很多种方式进行选择，Spring AOP支持以下AspectJ切点指示器（PCD）用于表达式：

execution：用于匹配方法执行连接点。这是使用Spring AOP时使用的主要点切割指示器。

within：限制匹配到某些类型的连接点（使用Spring AOP时在匹配类型中声明的方法的执行）。

this：限制与连接点匹配（使用Spring AOP时方法的执行），其中bean引用（Spring AOP代理）是给定类型的实例。

target：限制匹配连接点（使用Spring AOP时方法的执行），其中目标对象（正在代理的应用程序对象）是给定类型的实例。

args：限制与连接点匹配（使用Spring AOP时方法的执行），其中参数是给定类型的实例。

@target：限制匹配连接点（使用Spring AOP时方法的执行），其中执行对象的类具有给定类型的注释。

@args：限制匹配到连接点（使用Spring AOP时方法的执行），其中传递的实际参数的运行时类型具有给定类型的注释。

@within：限制与具有给定注释的类型中的连接点匹配（使用Spring AOP时在带有给定注释的类型中声明的方法的执行）。

@annotation：与连接点主体（在Spring AOP中运行的方法）具有给定注释的连接点匹配的限制。

更多详细内容请查阅：https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#aop-pointcuts-designators

其中，我们主要学习的execution填写格式如下：

修饰符：public、protected、private、包括返回值类型、static等等（使用*代表任意修饰符）

包名：如com.test（* 代表全部，比如com.*代表com包下的全部包）

类名：使用*也可以代表包下的所有类

方法名称：可以使用*代表全部方法

方法参数：填写对应的参数即可，比如(String, String)，也可以使用*来代表任意一个参数，使用..代表所有参数。

也可以使用其他属性来进行匹配，比如@annotation可以用于表示标记了哪些注解的方法被切入，这里我们就只是简单的执行，所以说只需要这样写就可以了：

这样，我们就指明了需要切入的方法，然后就是将我们的增强方法，我们在里面继续添加aop:aspect标签，并使用ref属性将其指向我们刚刚注册的AOP类Bean：

接着就是添加后续动作了，当然，官方支持的有多种多样的，比如执行前、执行后、抛出异常后、方法返回后等等：

image-20221216155201849

其中around方法为环绕方法，自定义度会更高，我们会在稍后介绍。这里我们按照上面的要求，直接添加后续动作，注意需要指明生效的切点：

这样，我们就成功配置好了，配置正确会在旁边出现图标：

image-20221216155551779

我们来试试看吧：

结果如下：

image-20221216155616952

可以看到在我们原本的方法执行完成之后，它还继续执行了我们的增强方法，这实际上就是动态代理做到的，实现在不修改原有代码的基础上，对方法的调用进行各种增强，在之后的SpringMVC学习中，我们甚至可以使用它来快速配置访问日志打印。

前面我们说了，AOP是基于动态代理实现的，所以说我们如果直接获取Bean的类型，会发现不是原本的类型了：

image-20221216172042146

这里其实是Spring通过CGLib为我们生成的动态代理类，也就不难理解为什么调用方法会直接得到增强之后的结果了。包括我们前面讲解Spring的异步任务调度时，为什么能够直接实现异步，其实就是利用了AOP机制实现的方法增强。

虽然这些功能已经非常强大了，但是仅仅只能简单的切入还是不能满足一些需求，在某些情况下，我们可以需求方法执行的一些参数，比如方法执行之后返回了什么，或是方法开始之前传入了什么参数等等，现在我们修改一下Student中study方法的参数：

我们希望在增强的方法中也能拿到这个参数，然后进行处理：

这个时候，我们可以为我们切入的方法添加一个JoinPoint参数，通过此参数就可以快速获取切点位置的一些信息：

接着我们修改一下刚刚的AOP配置（因为方法参数有变动）看看结果吧：

现在我们来测试一下：

image-20221216160501469

是不是感觉大部分功能都可以通过AOP来完成了？

我们接着来看自定义度更高的环绕方法，现在我们希望在方法执行前和执行后都加入各种各样的动作，如果还是一个一个切点写，有点太慢了，能不能直接写一起呢，此时我们就可以使用环绕方法。

环绕方法相当于完全代理了此方法，它完全将此方法包含在中间，需要我们手动调用才可以执行此方法，并且我们可以直接获取更多的参数：

注意，如果代理方法存在返回值，那么环绕方法也需要有一个返回值，通过proceed方法来执行代理的方法，也可以修改参数之后调用proceed(Object[])，使用我们给定的参数再去执行：

这里我们还是以study方法为例，现在我们希望在调用前修改这个方法传入的参数值，改成我们自己的，然后在调用之后对返回值结果也进行处理：

现在我们编写一个环绕方法，对其进行全方面处理：

同样的，因为方法变动了，现在我们去修改一下我们的AOP配置：

image-20221216162003675

细心的小伙伴可能会发现，环绕方法的图标是全包的，跟我们之前的图标不太一样。

现在我们来试试看吧：

image-20221216161855358

这样，我们就实现了环绕方法，通过合理利用AOP带来的便捷，可以使得我们的代码更加清爽和优美。这里介绍一下 AOP 领域中的特性术语，防止自己下来看不懂文章：

通知（Advice）: AOP 框架中的增强处理，通知描述了切面何时执行以及如何执行增强处理，也就是我们上面编写的方法实现。

连接点（join point）: 连接点表示应用执行过程中能够插入切面的一个点，这个点可以是方法的调用、异常的抛出，实际上就是我们在方法执行前或是执行后需要做的内容。

切点（PointCut）: 可以插入增强处理的连接点，可以是方法执行之前也可以方法执行之后，还可以是抛出异常之类的。

切面（Aspect）: 切面是通知和切点的结合，我们之前在xml中定义的就是切面，包括很多信息。

引入（Introduction）：引入允许我们向现有的类添加新的方法或者属性。

织入（Weaving）: 将增强处理添加到目标对象中，并创建一个被增强的对象，我们之前都是在将我们的增强处理添加到目标对象，也就是织入（这名字挺有文艺范的）

使用接口实现AOP

前面我们介绍了如何使用xml配置一个AOP操作，这节课我们来看看如何使用Advice实现AOP。

它与我们之前学习的动态代理更接近一些，比如在方法开始执行之前或是执行之后会去调用我们实现的接口，首先我们需要将一个类实现Advice接口，只有实现此接口，才可以被通知，比如我们这里使用MethodBeforeAdvice表示是一个在方法执行之前的动作：

我们发现，方法中包括了很多的参数，其中args代表的是方法执行前得到的实参列表，还有target表示执行此方法的实例对象。运行之后，效果和之前是一样的，但是在这里我们就可以快速获取到更多信息。还是以简单的study方法为例：

我们来测试一下吧：

image-20221216164110367

除了此接口以外，还有其他的接口，比如AfterReturningAdvice就需要实现一个方法执行之后的操作：

因为使用的是接口，就非常方便，直接写一起，配置文件都不需要改了：

image-20221216164242506

我们也可以使用MethodInterceptor（同样也是Advice的子接口）进行更加环绕那样的自定义的增强，它用起来就真的像代理一样，例子如下：

我们来看看结果吧：

image-20221216173211310

使用起来还是挺简单的。

使用注解实现AOP

接着我们来看看如何使用注解实现AOP操作，现在变回我们之前的注解开发，首先我们需要在主类添加@EnableAspectJAutoProxy注解，开启AOP注解支持：

还是熟悉的玩法，类上直接添加@Component快速注册Bean：

接着我们需要在定义AOP增强操作的类上添加@Aspect注解和@Component将其注册为Bean即可，就像我们之前在配置文件中也要将其注册为Bean那样：

接着，我们可以在里面编写增强方法，并将此方法添加到一个切点中，比如我们希望在Student的study方法执行之前执行我们的before方法：

那么只需要添加@Before注解即可：

这样，这个方法就会在指定方法执行之前执行了，是不是感觉比XML配置方便多了。我们来测试一下：

image-20221216165625372

同样的，我们可以为其添加JoinPoint参数来获取切入点信息，使用方法跟之前一样：

为了更方便，我们还可以直接将参数放入，比如：

使用命名绑定模式，可以快速得到原方法的参数：

除了@Before，还有很多可以直接使用的注解，比如@AfterReturning、@AfterThrowing等，比如@AfterReturning：

同样的，环绕也可以直接通过注解声明：

实际上，无论是使用注解或是XML配置，我们要做的流程都是一样的，在之后的学习中，我们还会遇到更多需要使用AOP的地方。

数据库框架整合

学习了Spring之后，我们已经了解如何将一个类作为Bean交由IoC容器管理，这样，我们就可以通过更方便的方式来使用Mybatis框架，我们可以直接把SqlSessionFactory、Mapper交给Spring进行管理，并且可以通过注入的方式快速地使用它们。

因此，我们要学习一下如何将Mybatis与Spring进行整合，那么首先，我们需要在之前知识的基础上继续深化学习。

了解数据源

在之前，我们如果需要创建一个JDBC的连接，那么必须使用DriverManager.getConnection()来创建连接，连接建立后，我们才可以进行数据库操作。而学习了Mybatis之后，我们就不用再去使用DriverManager为我们提供连接对象，而是直接使用Mybatis为我们提供的SqlSessionFactory工具类来获取对应的SqlSession通过会话对象去操作数据库。

那么，它到底是如何封装JDBC的呢？我们可以试着来猜想一下，会不会是Mybatis每次都是帮助我们调用DriverManager来实现的数据库连接创建？我们可以看看Mybatis的源码：

在通过SqlSessionFactory调用openSession方法之后，它调用了内部的一个私有的方法openSessionFromDataSource，我们接着来看，这个方法里面定义了什么内容：

也就是说，我们的数据源配置信息，存放在了Transaction对象中，那么现在我们只需要知道执行器到底是如何执行SQL语句的，我们就知道到底如何创建Connection对象了，这时就需要获取数据库的链接信息了，那么我们来看看，这个DataSource到底是个什么：

我们发现，它是在javax.sql定义的一个接口，它包括了两个方法，都是用于获取连接的。因此，现在我们可以断定，并不是通过之前DriverManager的方法去获取连接了，而是使用DataSource的实现类来获取的，因此，也就正式引入到我们这一节的话题了：

数据库链接的建立和关闭是极其耗费系统资源的操作，通过DriverManager获取的数据库连接，一个数据库连接对象均对应一个物理数据库连接，每次操作都打开一个物理连接，使用完后立即关闭连接，频繁的打开、关闭连接会持续消耗网络资源，造成整个系统性能的低下。

因此，JDBC为我们定义了一个数据源的标准，也就是DataSource接口，告诉数据源数据库的连接信息，并将所有的连接全部交给数据源进行集中管理，当需要一个Connection对象时，可以向数据源申请，数据源会根据内部机制，合理地分配连接对象给我们。

一般比较常用的DataSource实现，都是采用池化技术，就是在一开始就创建好N个连接，这样之后使用就无需再次进行连接，而是直接使用现成的Connection对象进行数据库操作。

image-20221217134119558

当然，也可以使用传统的即用即连的方式获取Connection对象，Mybatis为我们提供了几个默认的数据源实现，我们之前一直在使用的是官方的默认配置，也就是池化数据源：

这里的type属性一共三个选项：

UNPOOLED 不使用连接池的数据源

POOLED 使用连接池的数据源

JNDI 使用JNDI实现的数据源

解读Mybatis数据源实现（选学）

前面我们介绍了DataSource数据源，那么我们就来看看，Mybatis到底是怎么实现的。我们先来看看，不使用池化的数据源实现，它叫做UnpooledDataSource，我们来看看源码：

首先这个类中定义了很多的成员，包括数据库的连接信息、数据库驱动信息、事务相关信息等。我们接着来看，它是如何实现DataSource中提供的接口方法的：

实际上，这两个方法都指向了内部的一个doGetConnection方法，那么我们接着来看：

这里将用户名和密码配置封装为一个Properties对象，然后执行另一个重载同名的方法：

到这里，就返回Connection对象了，而此对象正是通过DriverManager来创建的，因此，非池化的数据源实现依然使用的是传统的连接创建方式，那我们接着来看池化的数据源实现，它是PooledDataSource类：

我们发现，在这里的定义就比非池化的实现复杂得多了，因为它还要考虑并发的问题，并且还要考虑如何合理地存放大量的链接对象，该如何进行合理分配，因此它的玩法非常之高级，但是，再高级的玩法，我们都要拿下。

首先注意，它存放了一个UnpooledDataSource，此对象是在构造时就被创建，其实创建Connection还是依靠数据库驱动创建，我们后面慢慢解析，首先我们来看看它是如何实现接口方法的：

可以看到，它调用了popConnection()方法来获取连接对象，然后进行了一个代理，通过这方法名字我们可以猜测，有可能整个连接池就是一个类似于栈的集合类型结构实现的。那么我们接着来看看popConnection方法：

经过上面一顿猛如虎的操作之后，我们可以得到以下信息：

如果最后得到了连接对象（有可能是从空闲列表中得到，有可能是直接创建的新的，还有可能是经过回收策略回收得到的），那么连接(Connection)对象一定会被放在活跃列表中(state.activeConnections)

那么肯定有一个疑问，现在我们已经知道获取一个链接会直接进入到活跃列表中，那么，如果一个连接被关闭，又会发生什么事情呢，我们来看看此方法返回之后，会调用getProxyConnection来获取一个代理对象，实际上就是PooledConnection类：

它直接代理了构造方法中传入的Connection对象，也是使用JDK的动态代理实现的，那么我们来看一下，它是如何进行代理的：

这下，池化数据源的大致流程其实就已经很清晰了，那么我们最后再来看看pushConnection方法：

这样，我们就已经完全了解了Mybatis的池化数据源的执行流程了。只不过，无论Connection管理方式如何变换，无论数据源再高级，我们要知道，它都最终都会使用DriverManager来创建连接对象，而最终使用的也是DriverManager提供的Connection对象。

整合Mybatis框架

通过了解数据源，我们已经清楚，Mybatis实际上是在使用自己编写的数据源（数据源实现其实有很多，之后我们再聊其他的）默认使用的是池化数据源，它预先存储了很多的连接对象。

那么我们来看一下，如何将Mybatis与Spring更好的结合呢，比如我们现在希望将SqlSessionFactory交给IoC容器进行管理，而不是我们自己创建工具类来管理（我们之前一直都在使用工具类管理和创建会话）

在mybatis-spring依赖中，为我们提供了SqlSessionTemplate类，它其实就是官方封装的一个工具类，我们可以将其注册为Bean，这样我们随时都可以向IoC容器索要对象，而不用自己再去编写一个工具类了，我们可以直接在配置类中创建。对于这种别人编写的类型，如果要注册为Bean，那么只能在配置类中完成：

这里随便编写一个测试的Mapper类：

最后是配置文件：

我们来测试一下吧：

image-20221217142651610

这样，我们就成功将Mybatis与Spring完成了初步整合，直接从容器中就能获取到SqlSessionTemplate，结合自动注入，我们的代码量能够进一步的减少。

虽然这样已经很方便了，但是还不够方便，我们依然需要手动去获取Mapper对象，那么能否直接得到对应的Mapper对象呢，我们希望让Spring直接帮助我们管理所有的Mapper，当需要时，可以直接从容器中获取，我们可以直接在配置类上方添加注解：

这样，Mybatis就会自动扫描对应包下所有的接口，并直接被注册为对应的Mapper作为Bean管理，那么我们现在就可以直接通过容器获取了：

在我们后续的SpringBoot学习阶段，会有更加方便的方式来注册Mapper，我们只需要一个@Mapper注解即可完成，非常简单。

请一定注意，必须存在SqlSessionTemplate或是SqlSessionFactoryBean的Bean，否则会无法初始化（毕竟要数据库的链接信息）我们接着来看，如果我们希望直接去除Mybatis的配置文件，完全实现全注解配置，那么改怎么去实现呢？我们可以使用SqlSessionFactoryBean类：

首先我们需要创建一个数据源的实现类，因为这是数据库最基本的信息，然后再给到SqlSessionFactoryBean实例，这样，我们相当于直接在一开始通过IoC容器配置了SqlSessionFactory，这里只需要传入一个DataSource的实现即可，我们采用池化数据源。

删除配置文件，重新再来运行，同样可以正常使用Mapper。从这里开始，通过IoC容器，Mybatis已经不再需要使用配置文件了，在我们之后的学习中，基于Spring的开发将不会再出现Mybatis的配置文件。

使用HikariCP连接池

前面我们提到了数据源还有其他实现，比如C3P0、Druid等，它们都是非常优秀的数据源实现（可以自行了解），不过我们这里要介绍的，是之后在SpringBoot中还会遇到的HikariCP连接池。

HikariCP是由日本程序员开源的一个数据库连接池组件，代码非常轻量，并且速度非常的快。根据官方提供的数据，在酷睿i7开启32个线程32个连接的情况下，进行随机数据库读写操作，HikariCP的速度是现在常用的C3P0数据库连接池的数百倍。在SpringBoot 3.0中，官方也是推荐使用HikariCP。

image-20221217145126777

首先，我们需要导入依赖：

要更换数据源实现，非常简单，我们可以直接声明一个Bean：

最后我们发现，同样可以得到输出结果，但是出现了一个报错：

此数据源实际上是采用了SLF4J日志框架打印日志信息，但是现在没有任何的日志实现（slf4j只是一个API标准，它规范了多种日志框架的操作，统一使用SLF4J定义的方法来操作不同的日志框架，我们会在SpringBoot篇进行详细介绍）我们这里就使用JUL作为日志实现，我们需要导入另一个依赖：

注意版本一定要和slf4j-api保持一致，我们可以在这里直接查看：

image-20221217154216832

这样，HikariCP数据源的启动日志就可以正常打印出来了：

在SpringBoot阶段，我们还会遇到HikariPool-1 - Starting...和HikariPool-1 - Start completed.同款日志信息。

当然，Lombok肯定也是支持这个日志框架快速注解的：

是不是感觉特别方便？

Mybatis事务管理

我们前面已经讲解了如何让Mybatis与Spring更好地融合在一起，通过将对应的Bean类型注册到容器中，就能更加方便的去使用Mapper，那么现在，我们接着来看Spring的事务控制。

在开始之前，我们还是回顾一下事务机制。首先事务遵循一个ACID原则：

原子性（Atomicity）：事务是一个原子操作，由一系列动作组成。事务的原子性确保动作要么全部完成，要么完全不起作用。

一致性（Consistency）：一旦事务完成（不管成功还是失败），系统必须确保它所建模的业务处于一致的状态，而不会是部分完成部分失败。在现实中的数据不应该被破坏。类比银行转账，从一个账号扣款，另一个账号增款，必须保证总金额不变。

隔离性（Isolation）：可能有许多事务会同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。类比多个人同时编辑同一文档，每个人看到的结果都是独立的，不会受其他人的影响，不过难免会存在冲突。

持久性（Durability）：一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响，这样就能从任何系统崩溃中恢复过来。通常情况下，事务的结果被写到持久化存储器中。类比写入硬盘的文件，即使关机重启，文件仍然存在。

简单来说，事务就是要么完成，要么就啥都别做！并且不同的事务之间相互隔离，互不干扰。

那么我们接着来深入了解一下事务的隔离机制（在之前数据库入门阶段并没有提到）我们说了，事务之间是相互隔离互不干扰的，那么如果出现了下面的情况，会怎么样呢：

当两个事务同时在执行，并且同时在操作同一个数据，这样很容易出现并发相关的问题，比如一个事务先读取了某条数据，而另一个事务此时修改了此数据，当前一个事务紧接着再次读取时，会导致和前一次读取的数据不一致，这就是一种典型的数据虚读现象。

因此，为了解决这些问题，事务之间实际上是存在一些隔离级别的：

ISOLATION_READ_UNCOMMITTED（读未提交）：其他事务会读取当前事务尚未更改的提交（相当于读取的是这个事务暂时缓存的内容，并不是数据库中的内容）

ISOLATION_READ_COMMITTED（读已提交）：其他事务会读取当前事务已经提交的数据（也就是直接读取数据库中已经发生更改的内容）

ISOLATION_REPEATABLE_READ（可重复读）：其他事务会读取当前事务已经提交的数据并且其他事务执行过程中不允许再进行数据修改（注意这里仅仅是不允许修改数据）

ISOLATION_SERIALIZABLE（串行化）：它完全服从ACID原则，一个事务必须等待其他事务结束之后才能开始执行，相当于挨个执行，效率很低

我们依次来看看，不同的隔离级别会导致什么问题。首先是读未提交级别，此级别属于最低级别，相当于各个事务共享一个缓存区域，任何事务的操作都在这里进行。那么它会导致以下问题：

image-20221217155511058

也就是说，事务A最后得到的实际上是一个毫无意义的数据（事务B已经回滚了）我们称此数据为”脏数据”，这种现象称为脏读

我们接着来看读已提交级别，事务只能读取其他事务已经提交的内容，相当于直接从数据中读取数据，这样就可以避免脏读问题了，但是它还是存在以下问题：

image-20221217155538073

这正是我们前面例子中提到的问题，虽然它避免了脏读问题，但是如果事件B修改并提交了数据，那么实际上事务A之前读取到的数据依然不是最新的数据，直接导致两次读取的数据不一致，这种现象称为虚读也可以称为不可重复读

因此，下一个隔离级别可重复读就能够解决这样的问题（MySQL的默认隔离级别），它规定在其他事务执行时，不允许修改数据，这样，就可以有效地避免不可重复读的问题，但是这样就一定安全了吗？这里仅仅是禁止了事务执行过程中的UPDATE操作，但是它并没有禁止INSERT这类操作，因此，如果事务A执行过程中事务B插入了新的数据，那么A这时是毫不知情的，比如：

image-20221217160023674

两个人同时报名一个活动，两个报名的事务同时在进行，但是他们一开始读取到的人数都是5，而这时，它们都会认为报名成功后人数应该变成6，而正常情况下应该是7，因此这个时候就发生了数据的幻读现象。

因此，要解决这种问题，只能使用最后一种隔离级别串行化来实现了，每个事务不能同时进行，直接避免所有并发问题，简单粗暴，但是效率爆减，并不推荐。

最后总结三种情况：

脏读：读取到了被回滚的数据，它毫无意义。

虚读（不可重复读）：由于其他事务更新数据，两次读取的数据不一致。

幻读：由于其他事务执行插入删除操作，而又无法感知到表中记录条数发生变化，当下次再读取时会莫名其妙多出或缺失数据，就像产生幻觉一样。

（对于虚读和幻读的区分：虚读是某个数据前后读取不一致，幻读是整个表的记录数量前后读取不一致

最后这张图，请务必记在你的脑海，记在你的心中：

image-20221217160052616

Mybatis对于数据库的事务管理，也有着相应的封装。一个事务无非就是创建、提交、回滚、关闭，因此这些操作被Mybatis抽象为一个接口：

对于此接口的实现，MyBatis的事务管理分为两种形式：

使用JDBC的事务管理机制：即利用对应数据库的驱动生成的Connection对象完成对事务的提交（commit()）、回滚（rollback()）、关闭（close()）等，对应的实现类为JdbcTransaction

使用MANAGED的事务管理机制：这种机制MyBatis自身不会去实现事务管理，而是让程序的容器（比如Spring）来实现对事务的管理，对应的实现类为ManagedTransaction

如果需要自定义，那么得实现org.apache.ibatis.transaction.Transaction接口，然后在type属性中指定其类名。使用自定义的事务管理器可以根据具体需求来实现一些特定的事务管理行为。

而我们之前一直使用的其实就是JDBC的事务，相当于直接使用Connection对象（之前JavaWeb阶段已经讲解过了）在进行事务操作，并没有额外的管理机制，对应的配置为：

那么我们来看看JdbcTransaction是不是像我们上面所说的那样管理事务的，直接上源码：

相当于JdbcTransaction只是为数据库驱动提供的Connection对象套了层壳，所有的事务操作实际上是直接调用Connection对象。那么我们接着来看ManagedTransaction的源码：

我们发现，大体内容和JdbcTransaction差不多，但是它并没有实现任何的事务操作。也就是说，它希望将实现交给其他的管理框架来完成，而Spring就为Mybatis提供了一个非常好的事务管理实现。

使用Spring事务管理

现在我们来学习一下Spring提供的事务管理（Spring事务管理分为编程式事务和声明式事务，但是编程式事务过于复杂并且具有高度耦合性，违背了Spring框架的设计初衷，因此这里只讲解声明式事务）声明式事务是基于AOP实现的。

使用声明式事务非常简单，我们只需要在配置类添加@EnableTransactionManagement注解即可，这样就可以开启Spring的事务支持了。接着，我们只需要把一个事务要做的所有事情封装到Service层的一个方法中即可，首先需要在配置文件中注册一个新的Bean，事务需要执行必须有一个事务管理器：

接着我们来编写一个简单的Mapper操作：

这样会向数据库中插入一条新的学生信息，接着，假设我们这里有一个业务需要连续插入两条学生信息，首先编写业务层的接口：

接着，我们再来编写业务层的实现，我们可以直接将其注册为Bean，交给Spring来进行管理，这样就可以自动将Mapper注入到类中了，并且可以支持事务：

我们只需在方法上添加@Transactional注解，即可表示此方法执行的是一个事务操作，在调用此方法时，Spring会通过AOP机制为其进行增强，一旦发现异常，事务会自动回滚。最后我们来调用一下此方法：

得到的结果是出现错误：

我们发现，整个栈追踪信息中包含了大量aop包下的内容，也就印证了它确实是通过AOP实现的，那么我们接着来看一下，数据库中的数据是否没有发生变化（出现异常回滚了）

image-20221217161027254

结果显而易见，第一次的插入操作确实被回滚了，数据库中没有任何新增的内容。

我们接着来研究一下@Transactional注解的一些参数：

我们来讲解几个比较关键的属性：

transactionManager：指定事务管理器

propagation：事务传播规则，一个事务可以包括N个子事务

isolation：事务隔离级别，不多说了

timeout：事务超时时间

readOnly：是否为只读事务，不同的数据库会根据只读属性进行优化，比如MySQL一旦声明事务为只读，那么久不允许增删改操作了。

rollbackFor和noRollbackFor：发生指定异常时回滚或是不回滚，默认发生任何异常都回滚。

除了事务的传播规则，其他的内容其实已经给大家讲解过了，那么我们就来看看事务的传播。事务传播一共有七种级别：

image-20221217161156859

Spring默认的传播级别是PROPAGATION_REQUIRED，那么我们来看看，它是如何传播的，现在我们的Service类中一共存在两个事务，而一个事务方法包含了另一个事务方法：

最后我们得到结果，另一个事务也被回滚了，也就是说，相当于另一个事务直接加入到此事务中，也就是表中所描述的那样。如果单独执行test2()则会开启一个新的事务，而执行test()则会直接让内部的test2()加入到当前事务中。

现在我们将test2()的传播级别设定为SUPPORTS，那么这时如果单独调用test2()方法，并不会以事务的方式执行，当发生异常时，虽然依然存在AOP增强，但是不会进行回滚操作，而现在再调用test()方法，才会以事务的方式执行：

我们接着来看MANDATORY，它非常严格，如果当前方法并没有在任何事务中进行，会直接出现异常：

直接运行test2()方法，报错如下：

NESTED级别表示如果存在外层事务，则此方法单独创建一个子事务，回滚只会影响到此子事务，实际上就是利用创建Savepoint，然后回滚到此保存点实现的。NEVER级别表示此方法不应该加入到任何事务中，其余类型适用于同时操作多数据源情况下的分布式事务管理，这里暂时不做介绍。

集成JUnit测试

既然使用了Spring，那么怎么集成到JUnit中进行测试呢，首先大家能够想到的肯定是：

直接编写一个测试用例即可，但是这样的话，如果我们有很多个测试用例，那么我们不可能每次测试都去创建ApplicationContext吧？我们可以使用@Before添加一个测试前动作来提前配置ApplicationContext，但是这样的话，还是不够简便，能不能有更快速高效的方法呢？

Spring为我们提供了一个Test模块，它会自动集成Junit进行测试，我们可以导入一下依赖：

这里导入的是JUnit5和SpringTest模块依赖，然后直接在我们的测试类上添加两个注解就可以搞定：

@ExtendWith是由JUnit提供的注解，等同于旧版本的@RunWith注解，然后使用SpringTest模块提供的@ContextConfiguration注解来表示要加载哪一个配置文件，可以是XML文件也可以是类，我们这里就直接使用类进行加载。

配置完成后，我们可以直接使用@Autowired来进行依赖注入，并且直接在测试方法中使用注入的Bean，现在就非常方便了。

至此，SSM中的其中一个S（Spring）和一个M（Mybatis）就已经学完了，我们还剩下一个SpringMvc需要去学习，下一章，我们将重新回到Web开发，了解在Spring框架的加持下，我们如何更高效地开发Web应用程序。

实现原理探究（选学）

注意： 本版块难度很大，所有内容都作为选学内容。

如果学习Spring基本内容对你来说已经非常困难了，建议跳过此小节，直接进入MVC阶段的学习，此小节会从源码角度解释Spring的整个运行原理，对初学者来说等同于小学跨越到高中，它并不是必学内容，但是对于个人阅历提升极为重要（推荐完成整个SSM阶段的学习并且加以实战之后再来看此部分），如果你还是觉得自己能够跟上节奏继续深入钻研底层原理，那么现在就开始吧。

Bean工厂与Bean定义

实际上我们之前的所有操作都离不开一个东西，那就是IoC容器，那么它到底是如何实现呢？这一部分我们将详细介绍，首先我们大致了解一下ApplicationContext的加载流程：

image-20221217162656678

我们可以看到，整个过程极为复杂，一句话肯定是无法解释的。由于Spring的源码非常庞大，因此我们不可能再像了解其他框架那样直接自底向上逐行干源码了（各位可以自己点开看看，代码量非常多）

image-20221217162821241

我们只能对几个关键部分进行介绍，在了解这些内容之后，实际上不需要完全阅读所有部分的源码都可以有一个大致的认识。

首先，容器既然要管理Bean，那么肯定需要一个完善的管理机制，实际上，对Bean的管理都是依靠BeanFactory在进行，顾名思义BeanFactory就是对Bean进行生产和管理的工厂，我们可以尝试自己创建和使用BeanFactory对象：

我们可以直接找Bean工厂索要对象，只不过在一开始，工厂并不知道自己需要生产什么，可以生产什么，因此我们直接索要一个工厂不知道的Bean对象，会直接得到：

image-20230214193208233

我们只有告诉工厂我们要生产什么，怎么生产，工厂才能开工：

实际上，我们的ApplicationContext中就维护了一个AutowireCapableBeanFactory对象：

我们可以尝试获取一下：

正是因为这样，ApplicationContext才具有了管理和生产Bean对象的能力。

不过，我们的配置可能是XML、可能是配置类，那么Spring要如何进行解析，将这些变成对应的BeanDefinition对象呢？使用BeanDefinitionReader就可以：

因此，针对于不同类型的配置方式，ApplicationContext有着多种实现，其中常用的有：

ClassPathXmlApplicationContext：适用于类路径下的XML配置文件。

FileSystemXmlApplicationContext：适用于非类路径下的XML配置文件。

AnnotationConfigApplicationContext：适用于注解配置形式。

比如ClassPathXmlApplicationContext在初始化的时候就会创建一个对应的XmlBeanDefinitionReader进行扫描：

现在，我们就已经知道，Bean实际上是一开始通过BeanDefinitionReader进行扫描，然后将所有Bean以BeanDefinition对象的形式注册到对应的BeanFactory中进行集中管理，而我们使用的ApplicationContext实际上内部就有一个BeanFactory在进行Bean管理，这样容器才拥有了最基本的Bean管理功能。

当然，BeanFactory还可以具有父子关系，其中最关键的作用就是继承父容器中所有的Bean定义，这样的话，如果我们想要创建一个新的BeanFactory并且默认具有其他BeanFactory中所有的Bean定义外加一些其他的，那么就可以采用这种形式，这是很方便的。

我们可以来尝试一下，创建两个工厂：

现在我们来看看是不是我们想的那样：

同样的，我们在使用ApplicationContext时，也可以设定这样的父子关系，效果相同：

当然，除了这些功能之外，BeanFactory还提供了很多其他的管理Bean定义的方法，比如移除Bean定义、拷贝Bean定义、销毁单例Bean实例对象等功能，这里就不一一列出了，各位小伙伴自己调用一下测试就可以了，很简单。

单例Bean的创建与循环依赖

前面我们讲解了配置的Bean是如何被读取并加载到容器中的，接着我们来了解一下Bean实例对象是如何被创建并得到的，我们知道，如果要得到一个Bean的实例很简单，通过getBean方法就可以直接拿到了：

那么，一个Bean的实例对象到底是如何创建出来的呢？我们还要继续对我们之前讲解的BeanFactory进行深入介绍。

我们可以直接找到BeanFactory接口的一个抽象实现AbstractBeanFactory类，它实现了getBean()方法：

那么我们doGetBean()接着来看方法里面干了什么，这个方法比较长，我们分段进行讲解：

因为所有的Bean默认都是单例模式，对象只会存在一个，因此它会先调用父类的getSingleton()方法来直接获取单例对象，如果有的话，就可以直接拿到Bean的实例。如果Bean不是单例模式，那么会进入else代码块。这一部分我们先来看单例模式下的处理，其实逻辑非常简单：

实际上整个单例Bean的创建路线还是很清晰的，并没有什么很难理解的地方，在正常情况下，其实就是简单的创建对象实例并返回即可。

其中最关键的是它对于循环依赖的处理。我们发现，在上面的代码中，得到单例对象后，会有一个很特殊的判断isSingletonCurrentlyInCreation，这个是干嘛的？对象不应该直接创建出来吗？为什么会有这种正在创建的状态呢？我们来探究一下。

开始之前先给大家提个问题：

现在有两个Bean，A和B都是以原型模式进行创建，而A中需要注入B，B中需要注入A，这时就会出现A还未创建完成，就需要B，而B这时也没创建完成，因为B需要A，而A等着B，B又等着A，这样就只能无限循环下去了（就像死锁那种感觉）所以就出现了循环依赖的问题（同理，一个对象注入自己，还有三个对象之间，甚至多个对象之间也会出现这种情况）

但是，在单例模式下，由于每个Bean只会创建一个实例，只要能够处理好对象之间的引用关系，Spring完全有机会解决单例对象循环依赖的问题。那么单例模式下是如何解决循环依赖问题的呢？

image-20221217170912302

我们回到一开始的getSingleton()方法中，研究一下它到底是如何处理循环依赖的，它是可以自动解决循环依赖问题的：

看起来很复杂，实际上它使用了三级缓存的方式来处理循环依赖的问题，包括：

singletonObjects，用于保存实例化、注入、初始化完成的 bean 实例

earlySingletonObjects，用于保存实例化完成的 bean 实例

singletonFactories，在初始创建Bean对象时都会生成一个对应的单例工厂用于获取早期对象

我们先来画一个流程图理清整个过程：

image-20221218150012610

我们在了解这个流程之前，一定要先明确，单例Bean对象的获取，会有哪些结果，首先就是如果我们获取的Bean压根就没在工厂中注册，那得到的结果肯定是null；其次，如果我们获取的Bean已经注册了，那么肯定就可以得到这个单例对象，只是不清楚创建到哪一个阶段了。

现在我们根据上面的流程图，来模拟一下A和B循环依赖的情况：

image-20230214222056632

有的小伙伴就会有疑问了，看起来似乎两级缓存也可以解决问题啊，干嘛搞三层而且还搞个对象工厂？这不是多此一举吗？实际上这是为了满足Bean的生命周期而做的，通过工厂获取早期对象代码如下：

我们会在后面的部分中详细介绍BeanPostProcessor以及AOP的实现原理，届时各位再回来看就会明白了。

后置处理器与AOP

接着我们来介绍一下PostProcessor，它其实是Spring提供的一种后置处理机制，它可以让我们能够插手Bean、BeanFactory、BeanDefinition的创建过程，相当于进行一个最终的处理，而最后得到的结果（比如Bean实例、Bean定义等）就是经过后置处理器返回的结果，它是整个加载过程的最后一步。

而AOP机制正是通过它来实现的，我们首先来认识一下第一个接口BeanPostProcessor，它相当于Bean初始化的一个后置动作，我们可以直接实现此接口：

我们发现，此接口中包括两个方法，一个是postProcessAfterInitialization用于在Bean初始化之后进行处理，还有一个postProcessBeforeInitialization用于在Bean初始化之前进行处理，注意这里的初始化不是创建对象，而是调用类的初始化方法，比如：

而TestServiceImpl的加载顺序为：

现在我们再来总结一下一个Bean的加载流程：

[Bean定义]首先扫描Bean，加载Bean定义 -> 依赖注入根据Bean定义通过反射创建Bean实例 -> 依赖注入进行依赖注入（顺便解决循环依赖问题）-> [初始化Bean]BeanPostProcessor的初始化之前方法 -> [初始化Bean]Bean初始化方法 -> [初始化Bean]BeanPostProcessor的初始化之后方法 -> [完成]最终得到的Bean加载完成的实例

利用这种机制，理解Aop的实现过程就非常简单了，AOP实际上也是通过这种机制实现的，它的实现类是AnnotationAwareAspectJAutoProxyCreator，而它就是在最后对Bean进行了代理，因此最后我们得到的结果实际上就是一个动态代理的对象（有关详细实现过程，这里就不进行列举了，感兴趣的可以继续深入）因此，实际上之前设计的三层缓存，都是由于需要处理AOP设计的，因为在Bean创建得到最终对象之前，很有可能会被PostProcessor给偷梁换柱！

那么肯定有人有疑问了，这个类没有被注册啊，那按理说它不应该参与到Bean的初始化流程中的，为什么它直接就被加载了呢？

还记得@EnableAspectJAutoProxy吗？我们来看看它是如何定义就知道了：

我们发现它使用了@Import来注册AspectJAutoProxyRegistrar，那么这个类又是什么呢，我们接着来看：

它实现了接口，这个接口也是Spring提供的一种Bean加载机制，它支持直接向容器中添加Bean定义，容器也会加载这个Bean：

ImportBeanDefinitionRegistrar类只能通过其他类@Import的方式来加载，通常是启动类或配置类。

使用@Import，如果括号中的类是ImportBeanDefinitionRegistrar的实现类，则会调用接口中方法（一般用于注册Bean）

实现该接口的类拥有注册bean的能力。

我们可以看到此接口提供了一个BeanDefinitionRegistry正是用于注册Bean的定义的。

因此，当我们打上了@EnableAspectJAutoProxy注解之后，首先会通过@Import加载AspectJAutoProxyRegistrar，然后调用其registerBeanDefinitions方法，然后使用工具类注册AnnotationAwareAspectJAutoProxyCreator到容器中，这样在每个Bean创建之后，如果需要使用AOP，那么就会通过AOP的后置处理器进行处理，最后返回一个代理对象。

我们也可以尝试编写一个自己的ImportBeanDefinitionRegistrar实现，首先编写一个测试Bean：

观察控制台输出，成功加载Bean实例。

与BeanPostProcessor差不多的还有BeanFactoryPostProcessor，它和前者一样，也是用于我们自己处理后置动作的，不过这里是用于处理BeanFactory加载的后置动作，BeanDefinitionRegistryPostProcessor直接继承自BeanFactoryPostProcessor，并且还添加了新的动作postProcessBeanDefinitionRegistry，你可以在这里动态添加Bean定义或是修改已经存在的Bean定义，这里我们就直接演示BeanDefinitionRegistryPostProcessor的实现：

在这里注册Bean定义其实和之前那种方法效果一样。

最后，我们再完善一下Bean加载流程（加粗部分是新增的）：

[Bean定义]首先扫描Bean，加载Bean定义 -> [Bean定义]Bean定义和Bean工厂后置处理 -> 依赖注入根据Bean定义通过反射创建Bean实例 -> 依赖注入进行依赖注入（顺便解决循环依赖问题）-> [初始化Bean]BeanPostProcessor的初始化之前方法 -> [初始化Bean]Bean初始化方法 -> [初始化Bean]BeanPostProcessor的初始化之前后方法 -> [完成]最终得到的Bean加载完成的实例

应用程序上下文详解

前面我们详细介绍了BeanFactory是如何工作的，接着我们来研究一下ApplicationContext的内部，实际上我们真正在项目中使用的就是ApplicationContext的实现，那么它又是如何工作的呢。

它本身是一个接口，同时集成了多种类型的BeanFactory接口，说明它应该具有这些BeanFactory的能力，实际上我们在前面已经提到过，ApplicationContext是依靠内部维护的BeanFactory对象来完成这些功能的，并不是它本身就实现了这些功能。

这里我们就先从构造方法开始走起，以我们常用的AnnotationConfigApplicationContext为例：

先来看第一步：

这样，AnnotationConfigApplicationContext的基本内容就初始化好了，不过这里结束之后会将ConfigurationClassPostProcessor后置处理器加入到BeanFactory中，它继承自BeanFactoryPostProcessor，也就是说一会会在BeanFactory初始化完成之后进行后置处理：

实际上这个后置处理器的主要目的就是为了读取配置类中的各种Bean定义以及其他注解，比如@Import、@ComponentScan等。

同时这里也会注册一个AutowiredAnnotationBeanPostProcessor后置处理器到BeanFactory，它继承自BeanPostProcessor，用于处理后续生成的Bean对象，其实看名字就知道，这玩意就是为了处理@Autowire、@Value这种注解，用于自动注入，这里就不深入讲解具体实现了。

所以，第一步结束之后，就会有这两个关键的后置处理器放在容器中：

image-20230719152546148

接着是第二步，注册配置类：

现在配置类已经成功注册到IoC容器中了，我们接着来看第三步，到目前为止，我们已知的仅仅是注册了配置类的Bean，而刷新操作就是配置所有Bean的关键部分了，刷新操作是在 AbstractApplicationContext 中实现的：

所以，现在流程就很清晰了，实际上最主要的就是refresh方法，它从初始化到实例化所有的Bean整个流程都已经完成，在这个方法结束之后，整个IoC容器基本就可以正常使用了。

我们继续来研究一下finishBeanFactoryInitialization方法，看看它是怎么加载所有Bean的：

至此，关于Spring容器核心加载流程，我们就探究完毕了，实际单易懂，就是代码量太大了。在后续的SpringBoot阶段，我们还会继续深挖Spring的某些机制的具体实现细节。

Mybatis整合原理

通过之前的了解，我们再来看Mybatis的@MapperScan是如何实现的，现在理解起来就非常简单了。

我们可以直接打开查看：

我们发现，和Aop一样，它也是通过Registrar机制，通过@Import来进行Bean的注册，我们来看看MapperScannerRegistrar是个什么东西，关键代码如下：

虽然很长很多，但是这些代码都是在添加一些Bean定义的属性，而最关键的则是最上方的MapperScannerConfigurer，Mybatis将其Bean信息注册到了容器中，那么这个类又是干嘛的呢？

它实现了BeanDefinitionRegistryPostProcessor，也就是说它为Bean信息加载提供了后置处理，我们接着来看看它在Bean信息后置处理中做了什么：

开始扫描后，会调用doScan()方法，我们接着来看（这是ClassPathMapperScanner中的扫描方法）：

通过断点我们发现，最后处理得到的Bean定义发现此Bean是一个MapperFactoryBean，它不同于普通的Bean，FactoryBean相当于为普通的Bean添加了一层外壳，它并不是依靠Spring直接通过反射创建，而是使用接口中的方法：

通过getObject()方法，就可以获取到Bean的实例了。

注意这里一定要区分FactoryBean和BeanFactory的概念：

BeanFactory是个Factory，也就是 IOC 容器或对象工厂，所有的 Bean 都是由 BeanFactory( 也就是 IOC 容器 ) 来进行管理。

FactoryBean是一个能生产或者修饰生成对象的工厂Bean(本质上也是一个Bean)，可以在BeanFactory（IOC容器）中被管理，所以它并不是一个简单的Bean。当使用容器中factory bean的时候，该容器不会返回factory bean本身，而是返回其生成的对象。要想获取FactoryBean的实现类本身，得在getBean(String BeanName)中的BeanName之前加上&,写成getBean(String &BeanName)。

我们也可以自己编写一个实现：

因此，实际上我们的Mapper最终就以FactoryBean的形式，被注册到容器中进行加载了：

这样，整个Mybatis的@MapperScan的原理就全部解释完毕了。

在了解完了Spring的底层原理之后，我们其实已经完全可以根据这些实现原理来手写一个Spring框架了。