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

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

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

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

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

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

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

比如下面的情况：

1
2
3
4
5
6
7
8
9
10
11
12

class A{
    private List<B> list;
    public B test(B b){
        return null;
    }
}

class C{
    public C(B b){}
}

class B{ }

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

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

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

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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public static void main(String[] args) {
        A a = new A();
      a.test(IoC.getBean(Service.class));   //瞎编的一个容器类，但是是那个意思
      //比如现在在IoC容器中管理的Service的实现是B，那么我们从里面拿到的Service实现就是B
}

class A{
    private List<Service> list;   //一律使用Service，具体实现由IoC容器提供
    public Service test(Service b){
        return null;
    }
}

interface Service{ }   //使用Service做一个顶层抽象

class B implements Service{}  //B依然是具体实现类，并交给IoC容器管理

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

1
2
3

interface Service{ }

class D implements Service{}   //现在实现类变成了D，但是之前的代码并不会报错

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

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

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

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

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

1
2
3
4
5

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>6.0.10</version>
</dependency>

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

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

如果在使用Spring框架的过程中出现如下警告：

1
2
3

12月 17, 2022 3:26:26 下午 org.springframework.core.LocalVariableTableParameterNameDiscoverer inspectClass
警告: Using deprecated '-debug' fallback for parameter name resolution. Compile the affected code with '-parameters' instead or avoid its introspection: XXXX

这是因为LocalVariableTableParameterNameDiscoverer在Spring 6.0.1版本已经被标记为过时，并且即将移除，请在Maven配置文件中为编译插件添加 -parameters 编译参数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.10.1</version>
                <configuration>
                    <compilerArgs>
                        <arg>-parameters</arg>
                    </compilerArgs>
                </configuration>
            </plugin>
        </plugins>
    </pluginManagement>
</build>

没有此问题请无视这部分。

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

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

1
2
3
4
5
6

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd">
</beans>

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

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

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

1
2
3
4
5

public static void main(String[] args) {
      //ApplicationContext是应用程序上下文的顶层接口，它有很多种实现，这里我们先介绍第一种
      //因为这里使用的是XML配置文件，所以说我们就使用 ClassPathXmlApplicationContext 这个实现类
    ApplicationContext context = new ClassPathXmlApplicationContext("test.xml");  //这里写上刚刚的名字
}

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

1
2
3
4
5
6
7

package com.test.bean;

public class Student {
    public void hello(){
        System.out.println("Hello World!");
    }
}

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

1

<bean name="student" class="com.test.bean.Student"/>

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

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

1
2
3
4
5

public static void main(String[] args) {
    ApplicationContext context = new ClassPathXmlApplicationContext("test.xml");
    Student student = (Student) context.getBean("student");   //使用getBean方法来获取对应的对象（Bean）
    student.hello();
}

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

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

1
2
3
4

<?xml version="1.0" encoding="UTF-8"?>
<beans ...>
    <import resource="test.xml"/>
</beans>

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

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

1

<bean/>

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

1

<bean class="com.test.bean.Student"/>

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

1
2
3
4
5
6
7

public static void main(String[] args) {
    ApplicationContext context = new ClassPathXmlApplicationContext("test.xml");
      //getBean有多种形式，其中第一种就是根据类型获取对应的Bean
      //容器中只要注册了对应类的Bean或是对应类型子类的Bean，都可以获取到
    Student student = context.getBean(Student.class);
    student.hello();
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class ArtStudent extends Student{
      public void art(){
        System.out.println("我爱画画");
    }
}

public class SportStudent extends Student{
        public void sport(){
        System.out.println("我爱运动");
    }
}

<bean class="com.test.bean.ArtStudent"/>
<bean class="com.test.bean.SportStudent"/>

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

1
2

Student student = context.getBean(Student.class);
student.hello();

运行时得到如下报错：

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

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

1
2

ArtStudent student = context.getBean(ArtStudent.class);
student.art();

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

1
2

<bean class="com.test.bean.Student"/>
<bean class="com.test.bean.Student"/>

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

1
2

<bean name="art" class="com.test.bean.ArtStudent"/>
<bean name="sport" class="com.test.bean.SportStudent"/>

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

1
2

<bean name="a" class="com.test.bean.Student"/>
<bean name="b" class="com.test.bean.Student"/>

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

1
2

Student student = (Student) context.getBean("a");
student.hello();

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

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

1
2

<bean name="a" class="com.test.bean.Student"/>
<alias name="a" alias="test"/>

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

1
2

Student student = (Student) context.getBean("test");
student.hello();

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

1
2
3

Student student1 = context.getBean(Student.class);
Student student2 = context.getBean(Student.class);
System.out.println(student1 == student2);   //默认为单例模式，对象始终为同一个

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

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

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

1
2
3

Student student1 = context.getBean(Student.class);  //原型模式下，对象不再始终是同一个了
Student student2 = context.getBean(Student.class);
System.out.println(student1 == student2);

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

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

1

<bean class="com.test.bean.Student" lazy-init="true"/>

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

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

1
2

<bean name="teacher" class="com.test.bean.Teacher"/>
<bean name="student" class="com.test.bean.Student" depends-on="teacher"/>

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

1
2
3

public interface Teacher {
    void teach();
}

具体的实现有两个：

1
2
3
4
5
6
7
8
9
10
11
12
13

public class ArtTeacher implements Teacher{
    @Override
    public void teach() {
        System.out.println("我是美术老师，我教你画画！");
    }
}

public class ProgramTeacher implements Teacher{
    @Override
    public void teach() {
        System.out.println("我是编程老师，我教你学Golang！");
    }
}

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

1
2
3
4
5
6
7

public class Student {
    private Teacher teacher = new ArtTeacher();   
      //在以前，如果我们需要制定哪个老师教我们，直接new创建对应的对象就可以了
    public void study(){
        teacher.teach();
    }
}

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

1
2
3

public class Student {
    private Teacher teacher = new ProgramTeacher();
      ...

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

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

1
2
3
4

<bean name="teacher" class="com.test.bean.ProgramTeacher"/>
<bean name="student" class="com.test.bean.Student">
    <property name="teacher" ref="teacher"/>
</bean>

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

1
2
3
4
5
6
7

public class Student {
    private Teacher teacher;
      //要使用依赖注入，我们必须提供一个set方法（无论成员变量的访问权限是什么）命名规则依然是驼峰命名法
    public void setTeacher(Teacher teacher) {
        this.teacher = teacher;
    }
    ...

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

1
2

Student student = context.getBean(Student.class);
student.study();

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

1
2
3
4
5

<!--  只需要修改这里的class即可，现在改为ArtTeacher  -->
<bean name="teacher" class="com.test.bean.ArtTeacher"/>
<bean name="student" class="com.test.bean.Student">
    <property name="teacher" ref="teacher"/>
</bean>

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

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

1
2
3

<bean name="student" class="com.test.bean.Student">
    <property name="name" value="卢本伟"/>
</bean>

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

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

1
2
3
4
5
6
7

public class Student {
    private final Teacher teacher;   //构造方法中完成，所以说是一个final变量

    public Student(Teacher teacher){   //Teacher属性是在构造方法中完成的初始化
        this.teacher = teacher;
    }
      ...

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

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

1
2
3
4

<bean name="teacher" class="com.test.bean.ArtTeacher"/>
<bean name="student" class="com.test.bean.Student">
    <constructor-arg name="teacher" ref="teacher"/>
</bean>

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12

public class Student {
    private final String name;
    public Student(String name){
        System.out.println("我是一号构造方法");
        this.name = name;
    }

    public Student(int age){
        System.out.println("我是二号构造方法");
        this.name = String.valueOf(age);
    }
}

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

1

<constructor-arg value="1" type="int"/>

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

1

<constructor-arg value="1" name="age"/>

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

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

1
2
3
4
5
6
7

public class Student {
    private List<String> list;

    public void setList(List<String> list) {
        this.list = list;
    }
}

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

1
2
3
4
5
6
7
8
9
10

<bean name="student" class="com.test.bean.Student">
      <!--  对于集合类型，我们可以直接使用标签编辑集合的默认值  -->
    <property name="list">
        <list>
            <value>AAA</value>
            <value>BBB</value>
            <value>CCC</value>
        </list>
    </property>
</bean>

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

1
2
3
4
5
6
7
8
9

<bean name="student" class="com.test.bean.Student">
    <property name="map">
        <map>
            <entry key="语文" value="100.0"/>
            <entry key="数学" value="80.0"/>
            <entry key="英语" value="92.5"/>
        </map>
    </property>
</bean>

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

1
2
3

<bean name="student" class="com.test.bean.Student">
    <property name="teacher" ref="teacher"/>
</bean>

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

1

<bean name="student" class="com.test.bean.Student" autowire="byType"/>

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

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

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

1

<bean name="student" class="com.test.bean.Student" autowire="constructor"/>

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

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

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

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

1
2
3

<bean name="teacher" class="com.test.bean.ArtTeacher"/>
<bean name="teacher2" class="com.test.bean.ProgramTeacher" autowire-candidate="false"/>
<bean name="student" class="com.test.bean.Student" autowire="byType"/>

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

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

1
2
3

<bean name="teacher" class="com.test.bean.ArtTeacher" primary="true"/>
<bean name="teacher2" class="com.test.bean.ProgramTeacher"/>
<bean name="student" class="com.test.bean.Student" autowire="byType"/>

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

1
2
3
4
5
6
7

public void init(){
    System.out.println("我是对象初始化时要做的事情！");    
}

public void destroy(){
    System.out.println("我是对象销毁时要做的事情！");
}

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

1

<bean name="student" class="com.test.bean.Student" init-method="init" destroy-method="destroy"/>

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

1
2
3
4

//当容器创建时，默认情况下Bean都是单例的，那么都会在一开始就加载好，对象构造完成后，会执行init-method
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("test.xml");
//我们可以调用close方法关闭容器，此时容器内存放的Bean也会被一起销毁，会执行destroy-method
context.close();

所以说，最后的结果为：

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

1
2
3
4
5
6
7
8
9
10
11
12

public class Student {
    Student() {
        System.out.println("我被构造了");
    }
}

public class StudentFactory {
    public static Student getStudent(){
          System.out.println("欢迎光临电子厂");
        return new Student();
    }
}

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

1

<bean class="com.test.bean.StudentFactory" factory-method="getStudent"/>

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

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

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

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

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

1
2
3
4
5
6

public class StudentFactory {
    public Student getStudent(){
        System.out.println("欢迎光临电子厂");
        return new Student();
    }
}

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

1

<bean name="studentFactory" class="com.test.bean.StudentFactory"/>

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

1

<bean factory-bean="studentFactory" factory-method="getStudent"/>

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

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

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

1

Student bean = (Student) context.getBean("studentFactory");

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

1

StudentFactory bean = (StudentFactory) context.getBean("&studentFactory");

又是一个小细节。

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

1

ApplicationContext context = new AnnotationConfigApplicationContext();

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

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

1
2
3
4
5
6

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd">
</beans>

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

1
2
3

@Configuration
public class MainConfiguration {
}

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

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

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

1
2

ApplicationContext context = new AnnotationConfigApplicationContext(MainConfiguration.class);
//这个构造方法可以接收多个配置类（更准确的说是多个组件）

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

1
2
3
4
5
6
7
8

@Configuration
public class MainConfiguration {

    @Bean("student")
    public Student student(){
        return new Student();
    }
}

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

1
2
3
4
5
6
7

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean name = "student" class="com.test.bean.Student"/>
</beans>

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

1
2
3

@Import(LBWConfiguration.class)  //在讲解到Spring原理时，我们还会遇到它，目前只做了解即可。
@Configuration
public class MainConfiguration {

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

1
2
3

ApplicationContext context = new AnnotationConfigApplicationContext(MainConfiguration.class);
Student student = context.getBean(Student.class);
System.out.println(student);

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

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

1
2
3
4

@Bean(name = "", initMethod = "", destroyMethod = "", autowireCandidate = false)
public Student student(){
    return new Student();
}

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

1
2
3
4
5
6
7

@Bean
@Lazy(true)     //对应lazy-init属性
@Scope("prototype")    //对应scope属性
@DependsOn("teacher")    //对应depends-on属性
public Student student(){
    return new Student();
}

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

1
2
3
4

<bean name="teacher" class="com.test.bean.ProgramTeacher"/>
<bean name="student" class="com.test.bean.Student">
    <property name="teacher" ref="teacher"/>
</bean>

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

1
2
3
4
5
6
7
8
9
10
11
12

@Configuration
public class MainConfiguration {
    @Bean
    public Teacher teacher(){
        return new Teacher();
    }

    @Bean
    public Student student(Teacher teacher){
        return new Student(teacher);
    }
}

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

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

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

1
2
3
4

public class Student {
    @Autowired   //使用此注解来进行自动装配，由IoC容器自动为其赋值
    private Teacher teacher;
}

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

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

1
2
3
4
5
6
7
8

public class Student {
    private Teacher teacher;

    @Autowired
    public void setTeacher(Teacher teacher) {
        this.teacher = teacher;
    }
}

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

1
2
3
4
5
6
7
8
9

@Bean("a")
public Teacher teacherA(){
    return new Teacher();
}

@Bean("b")
public Teacher teacherB(){
    return new Teacher();
}

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

1
2
3
4
5

public class Student {
    @Autowired
    @Qualifier("a")   //匹配名称为a的Teacher类型的Bean
    private Teacher teacher;
}

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

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

1
2
3
4
5

<dependency>
    <groupId>jakarta.annotation</groupId>
    <artifactId>jakarta.annotation-api</artifactId>
    <version>2.1.1</version>
</dependency>

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

1
2
3
4

public class Student {
    @Resource
    private Teacher teacher;
}

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

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

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

1
2
3
4
5
6
7
8
9

@PostConstruct
public void init(){
    System.out.println("我是初始化方法");
}

@PreDestroy
public void destroy(){
    System.out.println("我是销毁方法");
}

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

1
2
3

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(MainConfiguration.class);
Student student = context.getBean(Student.class);
context.close();

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

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

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

1
2
3
4

@Component("lbwnb")   //同样可以自己起名字
public class Student {

}

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

1
2
3
4
5

@Configuration
@ComponentScan("com.test.bean")   //包扫描，这样Spring就会去扫描对应包下所有的类
public class MainConfiguration {

}

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

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

1
2
3

@Component
public class Student {
}

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

1
2

Student student = (Student) context.getBean("student");   //这样同样可以获取到
System.out.println(student);

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

1
2
3
4
5
6
7

@Bean
public Student artStudent(){
    return new Student();
}

Student student = (Student) context.getBean("artStudent");
System.out.println(student);

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

1
2
3
4
5
6
7

@Component
public class Student {
    Teacher teacher;
    public Student(Teacher teacher){   //如果有Teacher类型的Bean，那么这里的参数会被自动注入
        this.teacher = teacher;
    }
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@Component
public class StudentFactory implements FactoryBean<Student> {
    @Override
    public Student getObject() {   //生产的Bean对象
        return new Student();
    }

    @Override
    public Class<?> getObjectType() {   //生产的Bean类型
        return Student.class;
    }

    @Override
    public boolean isSingleton() {   //生产的Bean是否采用单例模式
        return false;
    }
}

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

请注意，使用注解虽然可以省事很多，代码也能变得更简洁，但是这并不代表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.

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

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

1
2
3
4
5
6
7
8

@Component
public class Student implements BeanNameAware {   //我们只需要实现这个接口就可以了

    @Override
    public void setBeanName(String name) {   //Bean在加载的时候，容器就会自动调用此方法，将Bean的名称给到我们
        System.out.println("我在加载阶段获得了Bean名字："+name);
    }
}

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

1
2
3
4
5
6
7
8

@Component
public class Student implements BeanClassLoaderAware {

    @Override
    public void setBeanClassLoader(ClassLoader classLoader) {
        System.out.println(classLoader);
    }
}

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

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

1
2
3
4
5

@EnableAsync
@Configuration
@ComponentScan("com.test.bean")
public class MainConfiguration {
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@Component
public class Student {
    public void syncTest() throws InterruptedException {
        System.out.println(Thread.currentThread().getName()+"我是同步执行的方法，开始...");
        Thread.sleep(3000);
        System.out.println("我是同步执行的方法，结束！");
    }

    @Async
    public void asyncTest() throws InterruptedException {
        System.out.println(Thread.currentThread().getName()+"我是异步执行的方法，开始...");
        Thread.sleep(3000);
        System.out.println("我是异步执行的方法，结束！");
    }
}

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

1
2
3
4
5
6

public static void main(String[] args) throws InterruptedException {
    AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(MainConfiguration.class);
    Student student = context.getBean(Student.class);
    student.asyncTest();   //异步执行
    student.syncTest();    //同步执行
}

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

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

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

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

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

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

1
2

Student student = context.getBean(Student.class);
System.out.println(student.getClass());   //这里我们通过getClass来获取一下类型，你会发现惊喜

我们来看看结果：

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

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

1
2
3
4
5

@EnableScheduling
@Configuration
@ComponentScan("com.test.bean")
public class MainConfiguration {
}

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

1
2
3
4

@Scheduled(fixedRate = 2000)   //单位依然是毫秒，这里是每两秒钟打印一次
public void task(){
    System.out.println("我是定时任务！"+new Date());
}

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

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

1
2
3
4
5
6
7

@Component
public class TestListener implements ApplicationListener<ContextRefreshedEvent> {
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        System.out.println(event.getApplicationContext());   //可以直接通过事件获取到事件相关的东西
    }
}

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13

public class TestEvent extends ApplicationEvent {   //自定义事件需要继承ApplicationEvent
    public TestEvent(Object source) {
        super(source);
    }
}

@Component
public class TestListener implements ApplicationListener<TestEvent> {
    @Override
    public void onApplicationEvent(TestEvent event) {
        System.out.println("发生了一次自定义事件，成功监听到！");
    }
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@Component
public class TaskComponent  implements ApplicationEventPublisherAware {  
      //要发布事件，需要拿到ApplicationEventPublisher，这里我们通过Aware在初始化的时候拿到
      //实际上我们的ApplicationContext就是ApplicationEventPublisher的实现类，这里拿到的就是
      //我们创建的ApplicationContext对象
    ApplicationEventPublisher publisher;

    @Scheduled(fixedRate = 1000)   //一秒一次
    public void task(){
          //直接通过ApplicationEventPublisher的publishEvent方法发布事件
          //这样，所有这个事件的监听器，都会监听到这个事件发生了
        publisher.publishEvent(new TestEvent(this));
    }

    @Override
    public void setApplicationEventPublisher(ApplicationEventPublisher publisher) {
        this.publisher = publisher;
    }
}

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

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

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

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

1

test.name=只因

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

1
2
3
4
5
6

@Configuration
@ComponentScan("com.test.bean")
@PropertySource("classpath:test.properties")   //注意，类路径下的文件名称需要在前面加上classpath:
public class MainConfiguration{
    
}

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

1
2
3
4
5
6
7
8
9

@Component
public class Student {
    @Value("${test.name}")   //这里需要在外层套上 ${ }
    private String name;   //String会被自动赋值为配置文件中对应属性的值

    public void hello(){
        System.out.println("我的名字是："+name);
    }
}

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

我们来测试一下吧：

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13

@Component
public class Student {
    private final String name;

      //构造方法中的参数除了被自动注入外，我们也可以选择使用@Value进行注入
    public Student(@Value("${test.name}") String name){
        this.name = name;
    }

    public void hello(){
        System.out.println("我的名字是："+name);
    }
}

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

1
2
3
4

private final String name;
public Student(@Value("10") String name){   //只不过，这里都是常量值了，我干嘛不直接写到代码里呢
    this.name = name;
}

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

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

1
2
3

ExpressionParser parser = new SpelExpressionParser();
Expression exp = parser.parseExpression("'Hello World'");  //使用parseExpression方法来创建一个表达式
System.out.println(exp.getValue());   //表达式最终的运算结果可以通过getValue()获取

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

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

1
2

Expression exp = parser.parseExpression("'Hello World'.toUpperCase()");   //调用String的toUpperCase方法
System.out.println(exp.getValue());

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

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

1
2
3

//比如 String.getBytes() 方法，就是一个Getter，那么可以写成 bytes
Expression exp = parser.parseExpression("'Hello World'.bytes");
System.out.println(exp.getValue());

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

1
2

Expression exp = parser.parseExpression("'Hello World'.bytes.length");   //继续访问数组的length属性
System.out.println(exp.getValue());

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

1
2

Expression exp = parser.parseExpression("new String('hello world').toUpperCase()");
System.out.println(exp.getValue());

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@Component
public class Student {
    private final String name;
    public Student(@Value("${test.name}") String name){
        this.name = name;
    }

    public String getName() {    //比如下面要访问name属性，那么这个属性得可以访问才行，访问权限不够是不行的
        return name;
    }
}

Student student = context.getBean(Student.class);
ExpressionParser parser = new SpelExpressionParser();
Expression exp = parser.parseExpression("name");
System.out.println(exp.getValue(student));    //直接读取对象的name属性

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

1

Expression exp = parser.parseExpression("name.bytes.length");   //拿到name之后继续getBytes然后length

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

1
2

Expression exp = parser.parseExpression("name");
exp.setValue(student, "刻师傅");   //同样的，这个属性得有访问权限且能set才可以，否则会报错

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

1
2
3
4
5

Expression exp = parser.parseExpression("66 > 77");   //比较运算
System.out.println(exp.getValue());

Expression exp = parser.parseExpression("99 + 99 * 3");   //算数运算
System.out.println(exp.getValue());

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

1
2
3

Expression exp = parser.parseExpression("T(java.lang.Math).random()");   //由T()囊括，包含完整包名+类名
//Expression exp = parser.parseExpression("T(System).nanoTime()");   //默认导入的类可以不加包名
System.out.println(exp.getValue());

1
2
3
4
5

@Component
public class Student {
    public Map<String, String> map = Map.of("test", "你干嘛");
    public List<String> list = List.of("AAA", "BBB", "CCC");
}

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

1
2
3
4
5

Expression exp = parser.parseExpression("map['test']");  //对于Map这里映射型，可以直接使用map[key]来取出value
System.out.println(exp.getValue(student));

Expression exp = parser.parseExpression("list[2]");   //对于List、数组这类，可以直接使用[index]
System.out.println(exp.getValue(student));

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

1
2
3
4
5
6
7
8
9

Expression exp = parser.parseExpression("{5, 2, 1, 4, 6, 7, 0, 3, 9, 8}"); //使用{}来快速创建List集合
List value = (List) exp.getValue();
value.forEach(System.out::println);

Expression exp = parser.parseExpression("{{1, 2}, {3, 4}}");   //它是支持嵌套使用的

//创建Map也很简单，只需要key:value就可以了，怎么有股JSON味
Expression exp = parser.parseExpression("{name: '小明', info: {address: '北京市朝阳区', tel: 10086}}");
System.out.println(exp.getValue());

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

1
2
3
4
5
6
7
8
9
10
11
12
13

@Component
public class Student {
    public List<Clazz> list = List.of(new Clazz("高等数学", 4));

    public record Clazz(String name, int score){ }
}

//现在我们希望从list中获取那些满足我们条件的元素，并组成一个新的集合，我们可以使用.?运算符
Expression exp = parser.parseExpression("list.?[name == '高等数学']");
System.out.println(exp.getValue(student));

Expression exp = parser.parseExpression("list.?[score > 3]");   //选择学分大于3分的科目
System.out.println(exp.getValue(student));

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

1
2

Expression exp = parser.parseExpression("list.![name]");   //使用.!创建投影集合，这里创建的时课程名称组成的新集合
System.out.println(exp.getValue(student));

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

1
2

Expression exp = parser.parseExpression("name.toUpperCase()");   //如果Student对象中的name属性为null
System.out.println(exp.getValue(student));

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

1
2

if(student.name != null)
    System.out.println(student.name.toUpperCase());

Java 8之后能这样写：

1

Optional.ofNullable(student.name).ifPresent(System.out::println);

但是你如果写过Kotlin：

1

println(student.name?.toUpperCase());

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

1
2

Expression exp = parser.parseExpression("name?.toUpperCase()");
System.out.println(exp.getValue(student));

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

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

1
2
3

<bean id="numberGuess" class="org.spring.samples.NumberGuess">
    <property name="randomNumber" value="#{ T(java.lang.Math).random() * 100.0 }"/>
</bean>

或是使用注解开发：

1
2
3
4

public class FieldValueTestBean {
    @Value("#{ systemProperties['user.region'] }")
    private String defaultLocale;
}

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

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

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

1
2
3
4
5
6
7

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd">
</beans>

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

1
2
3
4
5

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-aspects</artifactId>
    <version>6.0.10</version>
</dependency>

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

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

1
2
3
4
5
6
7
8

public class Student {
    public void study(){
        System.out.println("室友还在打游戏，我狠狠的学Java，太爽了"); 
          //现在我们希望在这个方法执行完之后，打印一些其他的内容，在不修改原有代码的情况下，该怎么做呢？
    }
}

<bean class="org.example.entity.Student"/>

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

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

1
2
3
4
5
6

public class StudentAOP {
      //这个方法就是我们打算对其进行的增强操作
    public void afterStudy() {
        System.out.println("为什么毕业了他们都继承家产，我还倒给他们打工，我努力的意义在哪里...");
    }
}

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

1

<bean id="studentAOP" class="org.example.entity.StudentAOP"/>

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

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

1
2
3

<aop:config>

</aop:config>

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

1

<aop:pointcut id="test" expression=""/>

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

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

1
2
3
4
5
6

public class StudentAOP implements MethodBeforeAdvice {
    @Override
    public void before(Method method, Object[] args, Object target) throws Throwable {
        System.out.println("通过Advice实现AOP");
    }
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13

public class Student {
    public void study(){
        System.out.println("我是学习方法！");
    }
}

<bean id="student" class="org.example.entity.Student"/>
<bean id="studentAOP" class="org.example.entity.StudentAOP"/>
<aop:config>
    <aop:pointcut id="test" expression="execution(* org.example.entity.Student.study())"/>
      <!--  这里只需要添加我们刚刚写好的advisor就可以了，注意是Bean的名字  -->
    <aop:advisor advice-ref="studentAOP" pointcut-ref="test"/>
</aop:config>

我们来测试一下吧：

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

1
2
3
4
5
6
7
8
9
10
11

public class StudentAOP implements MethodBeforeAdvice, AfterReturningAdvice {
    @Override
    public void before(Method method, Object[] args, Object target) throws Throwable {
        System.out.println("通过Advice实现AOP");
    }

    @Override
    public void afterReturning(Object returnValue, Method method, Object[] args, Object target) throws Throwable {
        System.out.println("我是方法执行之后的结果，方法返回值为："+returnValue);
    }
}

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class Student {
    public String study(){
        System.out.println("我是学习方法！");
        return "lbwnb";
    }
}

public class StudentAOP implements MethodInterceptor {   //实现MethodInterceptor接口
    @Override
    public Object invoke(MethodInvocation invocation) throws Throwable {  //invoke方法就是代理方法
        Object value = invocation.proceed();   //跟之前一样，需要手动proceed()才能调用原方法
        return value+"增强";
    }
}

我们来看看结果吧：

使用起来还是挺简单的。

1
2
3
4
5

@EnableAspectJAutoProxy
@ComponentScan("org.example.entity")
@Configuration
public class MainConfiguration {
}

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

1
2
3
4
5
6

@Component
public class Student {
    public void study(){
        System.out.println("我是学习方法！");
    }
}

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

1
2
3
4
5

@Aspect
@Component
public class StudentAOP {

}

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

1
2
3

public void before(){
    System.out.println("我是之前执行的内容！");
}

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

1
2
3
4

@Before("execution(* org.example.entity.Student.study())")  //execution写法跟之前一样
public void before(){
    System.out.println("我是之前执行的内容！");
}

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

1
2
3
4
5

public static void main(String[] args) {
    ApplicationContext context = new AnnotationConfigApplicationContext(MainConfiguration.class);
    Student bean = context.getBean(Student.class);
    bean.study();
}

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

1
2
3
4
5

@Before("execution(* org.example.entity.Student.study())")
public void before(JoinPoint point){
    System.out.println("参数列表："+ Arrays.toString(point.getArgs()));
    System.out.println("我是之前执行的内容！");
}

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

1
2
3

public void study(String str){
    System.out.println("我是学习方法！");
}

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

1
2
3
4
5
6
7

@Before(value = "execution(* org.example.entity.Student.study(..)) && args(str)", argNames = "str")
//命名绑定模式就是根据下面的方法参数列表进行匹配
//这里args指明参数，注意需要跟原方法保持一致，然后在argNames中指明
public void before(String str){
    System.out.println(str);   //可以快速得到传入的参数
    System.out.println("我是之前执行的内容！");
}

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

1
2
3
4
5
6
7
8
9

public String study(){
    System.out.println("我是学习方法！");
    return "lbwnb";
}

@AfterReturning(value = "execution(* org.example.entity.Student.study())", argNames = "returnVal", returning = "returnVal")   //使用returning指定接收方法返回值的参数returnVal
public void afterReturn(Object returnVal){
    System.out.println("返回值是："+returnVal);
}

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

1
2
3
4
5
6
7

@Around("execution(* com.test.bean.Student.test(..))")
public Object around(ProceedingJoinPoint point) throws Throwable {
    System.out.println("方法执行之前！");
    Object val = point.proceed();
    System.out.println("方法执行之后！");
    return val;
}

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

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

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

1
2
3

public SqlSession openSession(boolean autoCommit) {
    return this.openSessionFromDataSource(this.configuration.getDefaultExecutorType(), (TransactionIsolationLevel)null, autoCommit);
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) {
    Transaction tx = null;

    DefaultSqlSession var8;
    try {
        //获取当前环境（由配置文件映射的对象实体）
        Environment environment = this.configuration.getEnvironment();
          //事务工厂（暂时不提，下一板块讲解）
        TransactionFactory transactionFactory = this.getTransactionFactoryFromEnvironment(environment);
          //配置文件中：<transactionManager type="JDBC"/>
          //生成事务（根据我们的配置，会默认生成JdbcTransaction），这里是关键，我们看到这里用到了environment.getDataSource()方法
        tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit);
          //执行器，包括全部的数据库操作方法定义，本质上是在使用执行器操作数据库，需要传入事务对象
        Executor executor = this.configuration.newExecutor(tx, execType);
          //封装为SqlSession对象
        var8 = new DefaultSqlSession(this.configuration, executor, autoCommit);
    } catch (Exception var12) {
        this.closeTransaction(tx);
        throw ExceptionFactory.wrapException("Error opening session.  Cause: " + var12, var12);
    } finally {
        ErrorContext.instance().reset();
    }

    return var8;
}

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

1
2
3
4
5
6
7

public interface DataSource  extends CommonDataSource, Wrapper {

  Connection getConnection() throws SQLException;

  Connection getConnection(String username, String password)
    throws SQLException;
}

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

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

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

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

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