目录

事务&AOP

1. 事务管理

1.1 事务回顾

1.2 Spring事务管理

1.2.1 案例

1.2.2 原因分析

1.2.3 Transactional注解

1.3 事务进阶

1.3.1 rollbackFor

1.3.3 propagation

1.3.3.1 介绍

1.3.3.2 案例

2. AOP基础

2.1 AOP概述

2.2 AOP快速入门

2.3 AOP核心概念

事务&AOP

1. 事务管理

1.1 事务回顾

在数据库阶段我们已学习过事务了，我们讲到：

事务是一组操作的集合，它是一个不可分割的工作单位。事务会把所有的操作作为一个整体，一起向数据库提交或者是撤销操作请求。所以这组操作要么同时成功，要么同时失败。

怎么样来控制这组操作，让这组操作同时成功或同时失败呢？此时就要涉及到事务的具体操作了。

事务的操作主要有三步：

开启事务（一组操作开始前，开启事务）：start transaction / begin ;提交事务（这组操作全部成功后，提交事务）：commit ;回滚事务（中间任何一个操作出现异常，回滚事务）：rollback ;

1.2 Spring事务管理

1.2.1 案例

简单的回顾了事务的概念以及事务的基本操作之后，接下来我们看一个事务管理案例：解散部门 （解散部门就是删除部门）

需求：当部门解散了不仅需要把部门信息删除了，还需要把该部门下的员工数据也删除了。

步骤：

根据ID删除部门数据根据部门ID删除该部门下的员工

代码实现：

DeptServiceImpl

@Slf4j@Servicepublic class DeptServiceImpl implements DeptService { @Autowired private DeptMapper deptMapper; @Autowired private EmpMapper empMapper; //根据部门id，删除部门信息及部门下的所有员工 @Override public void delete(Integer id){ //根据部门id删除部门信息 deptMapper.deleteById(id); //删除部门下的所有员工信息 empMapper.deleteByDeptId(id); }} DeptMapper

@Mapperpublic interface DeptMapper { /** * 根据id删除部门信息 * @param id 部门id */ @Delete("delete from dept where id = #{id}") void deleteById(Integer id);} EmpMapper

@Mapperpublic interface EmpMapper { //根据部门id删除部门下所有员工 @Delete("delete from emp where dept_id=#{deptId}") public int deleteByDeptId(Integer deptId); }

重启SpringBoot服务，使用postman测试部门删除：

代码正常情况下，dept表和Em表中的数据已删除

修改DeptServiceImpl类中代码，添加可能出现异常的代码：

@Slf4j@Servicepublic class DeptServiceImpl implements DeptService { @Autowired private DeptMapper deptMapper; @Autowired private EmpMapper empMapper; //根据部门id，删除部门信息及部门下的所有员工 @Override public void delete(Integer id){ //根据部门id删除部门信息 deptMapper.deleteById(id); //模拟：异常发生 int i = 1/0; //删除部门下的所有员工信息 empMapper.deleteByDeptId(id); }}

重启SpringBoot服务，使用postman测试部门删除：

查看数据库表：

删除了2号部门

2号部门下的员工数据没有删除

以上程序出现的问题：即使程序运行抛出了异常，部门依然删除了，但是部门下的员工却没有删除，造成了数据的不一致。

1.2.2 原因分析

原因：

先执行根据id删除部门的操作，这步执行完毕，数据库表 dept 中的数据就已经删除了。执行 1/0 操作，抛出异常抛出异常之前，下面所有的代码都不会执行了，根据部门ID删除该部门下的员工，这个操作也不会执行 。

此时就出现问题了，部门删除了，部门下的员工还在，业务操作前后数据不一致。

而要想保证操作前后，数据的一致性，就需要让解散部门中涉及到的两个业务操作，要么全部成功，要么全部失败 。 那我们如何，让这两个操作要么全部成功，要么全部失败呢 ？

那就可以通过事务来实现，因为一个事务中的多个业务操作，要么全部成功，要么全部失败。

此时，我们就需要在delete删除业务功能中添加事务。

在方法运行之前，开启事务，如果方法成功执行，就提交事务，如果方法执行的过程当中出现异常了，就回滚事务。

思考：开发中所有的业务操作，一旦我们要进行控制事务，是不是都是这样的套路？

答案：是的。

所以在spring框架当中就已经把事务控制的代码都已经封装好了，并不需要我们手动实现。我们使用了spring框架，我们只需要通过一个简单的注解@Transactional就搞定了。

1.2.3 Transactional注解

@Transactional作用：就是在当前这个方法执行开始之前来开启事务，方法执行完毕之后提交事务。如果在这个方法执行的过程当中出现了异常，就会进行事务的回滚操作。

@Transactional注解：我们一般会在业务层当中来控制事务，因为在业务层当中，一个业务功能可能会包含多个数据访问的操作。在业务层来控制事务，我们就可以将多个数据访问操作控制在一个事务范围内。

@Transactional注解书写位置：

方法 当前方法交给spring进行事务管理类 当前类中所有的方法都交由spring进行事务管理接口 接口下所有的实现类当中所有的方法都交给spring 进行事务管理

接下来，我们就可以在业务方法delete上加上 @Transactional 来控制事务 。

@Slf4j@Servicepublic class DeptServiceImpl implements DeptService { @Autowired private DeptMapper deptMapper; @Autowired private EmpMapper empMapper; @Override @Transactional //当前方法添加了事务管理 public void delete(Integer id){ //根据部门id删除部门信息 deptMapper.deleteById(id); //模拟：异常发生 int i = 1/0; //删除部门下的所有员工信息 empMapper.deleteByDeptId(id); }}

在业务功能上添加@Transactional注解进行事务管理后，我们重启SpringBoot服务，使用postman测试：

添加Spring事务管理后，由于服务端程序引发了异常，所以事务进行回滚

说明：可以在application.yml配置文件中开启事务管理日志，这样就可以在控制看到和事务相关的日志信息了

#spring事务管理日志logging: level: org.springframework.jdbc.support.JdbcTransactionManager: debug

1.3 事务进阶

前面我们通过spring事务管理注解@Transactional已经控制了业务层方法的事务。接下来我们要来详细的介绍一下@Transactional事务管理注解的使用细节。我们这里主要介绍@Transactional注解当中的两个常见的属性：

异常回滚的属性：rollbackFor事务传播行为：propagation

我们先来学习下rollbackFor属性。

1.3.1 rollbackFor

我们在之前编写的业务方法上添加了@Transactional注解，来实现事务管理。

@Transactionalpublic void delete(Integer id){ //根据部门id删除部门信息 deptMapper.deleteById(id); //模拟：异常发生 int i = 1/0; //删除部门下的所有员工信息 empMapper.deleteByDeptId(id); }

以上业务功能delete()方法在运行时，会引发除0的算数运算异常(运行时异常)，出现异常之后，由于我们在方法上加了@Transactional注解进行事务管理，所以发生异常会执行rollback回滚操作，从而保证事务操作前后数据是一致的。

下面我们在做一个测试，我们修改业务功能代码，在模拟异常的位置上直接抛出Exception异常（编译时异常）

@Transactionalpublic void delete(Integer id) throws Exception { //根据部门id删除部门信息 deptMapper.deleteById(id); //模拟：异常发生 if(true){ throw new Exception("出现异常了~~~"); } //删除部门下的所有员工信息 empMapper.deleteByDeptId(id); }

说明：在service中向上抛出一个Exception编译时异常之后，由于是controller调用service，所以在controller中要有异常处理代码，此时我们选择在controller中继续把异常向上抛。

@DeleteMapping("/depts/{id}")public Result delete(@PathVariable Integer id) throws Exception { //日志记录 log.info("根据id删除部门"); //调用service层功能 deptService.delete(id); //响应 return Result.success();}

重新启动服务后测试：

抛出异常之后事务会不会回滚

现有表中数据：

使用postman测试，删除5号部门

发生了Exception异常，但事务依然提交了

dept表中数据：

通过以上测试可以得出一个结论：默认情况下，只有出现RuntimeException(运行时异常)才会回滚事务。

假如我们想让所有的异常都回滚，需要来配置@Transactional注解当中的rollbackFor属性，通过rollbackFor这个属性可以指定出现何种异常类型回滚事务。

@Slf4j@Servicepublic class DeptServiceImpl implements DeptService { @Autowired private DeptMapper deptMapper; @Autowired private EmpMapper empMapper; @Override @Transactional(rollbackFor=Exception.class) public void delete(Integer id){ //根据部门id删除部门信息 deptMapper.deleteById(id); //模拟：异常发生 int num = id/0; //删除部门下的所有员工信息 empMapper.deleteByDeptId(id); }}

接下来我们重新启动服务，测试删除部门的操作：

控制台日志：执行了删除3号部门的操作， 因为异常又进行了事务回滚

数据表：3号部门没有删除

结论：

在Spring的事务管理中，默认只有运行时异常 RuntimeException才会回滚。如果还需要回滚指定类型的异常，可以通过rollbackFor属性来指定。

1.3.3 propagation

1.3.3.1 介绍

我们接着继续学习@Transactional注解当中的第二个属性propagation，这个属性是用来配置事务的传播行为的。

什么是事务的传播行为呢？

就是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何进行事务控制。

例如：两个事务方法，一个A方法，一个B方法。在这两个方法上都添加了@Transactional注解，就代表这两个方法都具有事务，而在A方法当中又去调用了B方法。

所谓事务的传播行为，指的就是在A方法运行的时候，首先会开启一个事务，在A方法当中又调用了B方法， B方法自身也具有事务，那么B方法在运行的时候，到底是加入到A方法的事务当中来，还是B方法在运行的时候新建一个事务？这个就涉及到了事务的传播行为。

我们要想控制事务的传播行为，在@Transactional注解的后面指定一个属性propagation，通过 propagation 属性来指定传播行为。接下来我们就来介绍一下常见的事务传播行为。

对于这些事务传播行为，我们只需要关注以下两个就可以了：

REQUIRED（默认值）REQUIRES_NEW

1.3.3.2 案例

接下来我们就通过一个案例来演示下事务传播行为propagation属性的使用。

**需求：**解散部门时需要记录操作日志

​ 由于解散部门是一个非常重要而且非常危险的操作，所以在业务当中要求每一次执行解散部门的操作都需要留下痕迹，就是要记录操作日志。而且还要求无论是执行成功了还是执行失败了，都需要留下痕迹。

步骤：

执行解散部门的业务：先删除部门，再删除部门下的员工（前面已实现）记录解散部门的日志，到日志表（未实现）

准备工作：

创建数据库表 dept_log 日志表：

create table dept_log( id int auto_increment comment '主键ID' primary key, create_time datetime null comment '操作时间', description varchar(300) null comment '操作描述')comment '部门操作日志表'; 引入资料中提供的实体类：DeptLog

@Data@NoArgsConstructor@AllArgsConstructorpublic class DeptLog { private Integer id; private LocalDateTime createTime; private String description;} 引入资料中提供的Mapper接口：DeptLogMapper

@Mapperpublic interface DeptLogMapper { @Insert("insert into dept_log(create_time,description) values(#{createTime},#{description})") void insert(DeptLog log);} 引入资料中提供的业务接口：DeptLogService

public interface DeptLogService { void insert(DeptLog deptLog);} 引入资料中提供的业务实现类：DeptLogServiceImpl

@Servicepublic class DeptLogServiceImpl implements DeptLogService { @Autowired private DeptLogMapper deptLogMapper; @Transactional //事务传播行为：有事务就加入、没有事务就新建事务 @Override public void insert(DeptLog deptLog) { deptLogMapper.insert(deptLog); }}

代码实现:

业务实现类：DeptServiceImpl

@Slf4j@Service//@Transactional //当前业务实现类中的所有的方法，都添加了spring事务管理机制public class DeptServiceImpl implements DeptService { @Autowired private DeptMapper deptMapper; @Autowired private EmpMapper empMapper; @Autowired private DeptLogService deptLogService; //根据部门id，删除部门信息及部门下的所有员工 @Override @Log @Transactional(rollbackFor = Exception.class) public void delete(Integer id) throws Exception { try { //根据部门id删除部门信息 deptMapper.deleteById(id); //模拟：异常 if(true){ throw new Exception("出现异常了~~~"); } //删除部门下的所有员工信息 empMapper.deleteByDeptId(id); }finally { //不论是否有异常，最终都要执行的代码：记录日志 DeptLog deptLog = new DeptLog(); deptLog.setCreateTime(LocalDateTime.now()); deptLog.setDescription("执行了解散部门的操作，此时解散的是"+id+"号部门"); //调用其他业务类中的方法 deptLogService.insert(deptLog); } } //省略其他代码...}

测试:

重新启动SpringBoot服务，测试删除3号部门后会发生什么？

执行了删除3号部门操作执行了插入部门日志操作程序发生Exception异常执行事务回滚（删除、插入操作因为在一个事务范围内，两个操作都会被回滚）

然后在dept_log表中没有记录日志数据

原因分析:

接下来我们就需要来分析一下具体是什么原因导致的日志没有成功的记录。

在执行delete操作时开启了一个事务

当执行insert操作时，insert设置的事务传播行是默认值REQUIRED，表示有事务就加入，没有则新建事务

此时：delete和insert操作使用了同一个事务，同一个事务中的多个操作，要么同时成功，要么同时失败，所以当异常发生时进行事务回滚，就会回滚delete和insert操作

解决方案：

在DeptLogServiceImpl类中insert方法上，添加@Transactional(propagation = Propagation.REQUIRES_NEW)

Propagation.REQUIRES_NEW ：不论是否有事务，都创建新事务 ，运行在一个独立的事务中。

@Servicepublic class DeptLogServiceImpl implements DeptLogService { @Autowired private DeptLogMapper deptLogMapper; @Transactional(propagation = Propagation.REQUIRES_NEW)//事务传播行为：不论是否有事务，都新建事务 @Override public void insert(DeptLog deptLog) { deptLogMapper.insert(deptLog); }}

重启SpringBoot服务，再次测试删除3号部门：

那此时，DeptServiceImpl中的delete方法运行时，会开启一个事务。 当调用 deptLogService.insert(deptLog) 时，也会创建一个新的事务，那此时，当insert方法运行完毕之后，事务就已经提交了。 即使外部的事务出现异常，内部已经提交的事务，也不会回滚了，因为是两个独立的事务。

到此事务传播行为已演示完成，事务的传播行为我们只需要掌握两个：REQUIRED、REQUIRES_NEW。

REQUIRED ：大部分情况下都是用该传播行为即可。

REQUIRES_NEW ：当我们不希望事务之间相互影响时，可以使用该传播行为。比如：下订单前需要记录日志，不论订单保存成功与否，都需要保证日志记录能够记录成功。

2. AOP基础

学习完spring的事务管理之后，接下来我们进入到AOP的学习。 AOP也是spring框架的第二大核心，我们先来学习AOP的基础。

在AOP基础这个阶段，我们首先介绍一下什么是AOP，再通过一个快速入门程序，让大家快速体验AOP程序的开发。最后再介绍AOP当中所涉及到的一些核心的概念。

2.1 AOP概述

什么是AOP？

AOP英文全称：Aspect Oriented Programming（面向切面编程、面向方面编程），其实说白了，面向切面编程就是面向特定方法编程。

那什么又是面向方法编程呢，为什么又需要面向方法编程呢？来我们举个例子做一个说明：

比如，我们这里有一个项目，项目中开发了很多的业务功能。

然而有一些业务功能执行效率比较低，执行耗时较长，我们需要针对于这些业务方法进行优化。 那首先第一步就需要定位出执行耗时比较长的业务方法，再针对于业务方法再来进行优化。

此时我们就需要统计当前这个项目当中每一个业务方法的执行耗时。那么统计每一个业务方法的执行耗时该怎么实现？

可能多数人首先想到的就是在每一个业务方法运行之前，记录这个方法运行的开始时间。在这个方法运行完毕之后，再来记录这个方法运行的结束时间。拿结束时间减去开始时间，不就是这个方法的执行耗时吗？

以上分析的实现方式是可以解决需求问题的。但是对于一个项目来讲，里面会包含很多的业务模块，每个业务模块又包含很多增删改查的方法，如果我们要在每一个模块下的业务方法中，添加记录开始时间、结束时间、计算执行耗时的代码，就会让程序员的工作变得非常繁琐。

而AOP面向方法编程，就可以做到在不改动这些原始方法的基础上，针对特定的方法进行功能的增强。

AOP的作用：在程序运行期间在不修改源代码的基础上对已有方法进行增强（无侵入性: 解耦）

我们要想完成统计各个业务方法执行耗时的需求，我们只需要定义一个模板方法，将记录方法执行耗时这一部分公共的逻辑代码，定义在模板方法当中，在这个方法开始运行之前，来记录这个方法运行的开始时间，在方法结束运行的时候，再来记录方法运行的结束时间，中间就来运行原始的业务方法。

20230112154530101

而中间运行的原始业务方法，可能是其中的一个业务方法，比如：我们只想通过 部门管理的 list 方法的执行耗时，那就只有这一个方法是原始业务方法。 而如果，我们是先想统计所有部门管理的业务方法执行耗时，那此时，所有的部门管理的业务方法都是 原始业务方法。 那面向这样的指定的一个或多个方法进行编程，我们就称之为 面向切面编程。

那此时，当我们再调用部门管理的 list 业务方法时啊，并不会直接执行 list 方法的逻辑，而是会执行我们所定义的 模板方法 ， 然后再模板方法中：

记录方法运行开始时间运行原始的业务方法（那此时原始的业务方法，就是 list 方法）记录方法运行结束时间，计算方法执行耗时

不论，我们运行的是那个业务方法，最后其实运行的就是我们定义的模板方法，而在模板方法中，就完成了原始方法执行耗时的统计操作 。(那这样呢，我们就通过一个模板方法就完成了指定的一个或多个业务方法执行耗时的统计)

而大家会发现，这个流程，我们是不是似曾相识啊？

对了，就是和我们之前所学习的动态代理技术是非常类似的。 我们所说的模板方法，其实就是代理对象中所定义的方法，那代理对象中的方法以及根据对应的业务需要， 完成了对应的业务功能，当运行原始业务方法时，就会运行代理对象中的方法，从而实现统计业务方法执行耗时的操作。

其实，AOP面向切面编程和OOP面向对象编程一样，它们都仅仅是一种编程思想，而动态代理技术是这种思想最主流的实现方式。而Spring的AOP是Spring框架的高级技术，旨在管理bean对象的过程中底层使用动态代理机制，对特定的方法进行编程(功能增强)。

AOP的优势：

减少重复代码提高开发效率维护方便

2.2 AOP快速入门

在了解了什么是AOP后，我们下面通过一个快速入门程序，体验下AOP的开发，并掌握Spring中AOP的开发步骤。

**需求：**统计各个业务层方法执行耗时。

实现步骤：

导入依赖：在pom.xml中导入AOP的依赖编写AOP程序：针对于特定方法根据业务需要进行编程

为演示方便，可以自建新项目或导入提供的springboot-aop-quickstart项目工程

pom.xml

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId></dependency>

AOP程序：TimeAspect

@Component@Aspect //当前类为切面类@Slf4jpublic class TimeAspect { @Around("execution(* com.itheima.service.*.*(..))") public Object recordTime(ProceedingJoinPoint pjp) throws Throwable { //记录方法执行开始时间 long begin = System.currentTimeMillis(); //执行原始方法 Object result = pjp.proceed(); //记录方法执行结束时间 long end = System.currentTimeMillis(); //计算方法执行耗时 log.info(pjp.getSignature()+"执行耗时: {}毫秒",end-begin); return result; }}

重新启动SpringBoot服务测试程序：

查询3号部门信息

我们可以再测试下：查询所有部门信息（同样执行AOP程序）

我们通过AOP入门程序完成了业务方法执行耗时的统计，那其实AOP的功能远不止于此，常见的应用场景如下：

记录系统的操作日志权限控制事务管理：我们前面所讲解的Spring事务管理，底层其实也是通过AOP来实现的，只要添加@Transactional注解之后，AOP程序自动会在原始方法运行前先来开启事务，在原始方法运行完毕之后提交或回滚事务

这些都是AOP应用的典型场景。

通过入门程序，我们也应该感受到了AOP面向切面编程的一些优势：

代码无侵入：没有修改原始的业务方法，就已经对原始的业务方法进行了功能的增强或者是功能的改变

减少了重复代码

提高开发效率

维护方便

2.3 AOP核心概念

通过SpringAOP的快速入门，感受了一下AOP面向切面编程的开发方式。下面我们再来学习AOP当中涉及到的一些核心概念。

1. 连接点：JoinPoint，可以被AOP控制的方法（暗含方法执行时的相关信息）

​ 连接点指的是可以被aop控制的方法。例如：入门程序当中所有的业务方法都是可以被aop控制的方法。

​

​ 在SpringAOP提供的JoinPoint当中，封装了连接点方法在执行时的相关信息。（后面会有具体的讲解）

2. 通知：Advice，指哪些重复的逻辑，也就是共性功能（最终体现为一个方法）

​ 在入门程序中是需要统计各个业务方法的执行耗时的，此时我们就需要在这些业务方法运行开始之前，先记录这个方法运行的开始时间，在每一个业务方法运行结束的时候，再来记录这个方法运行的结束时间。

​ 但是在AOP面向切面编程当中，我们只需要将这部分重复的代码逻辑抽取出来单独定义。抽取出来的这一部分重复的逻辑，也就是共性的功能。

​

3. 切入点：PointCut，匹配连接点的条件，通知仅会在切入点方法执行时被应用

​ 在通知当中，我们所定义的共性功能到底要应用在哪些方法上？此时就涉及到了切入点pointcut概念。切入点指的是匹配连接点的条件。通知仅会在切入点方法运行时才会被应用。

​ 在aop的开发当中，我们通常会通过一个切入点表达式来描述切入点(后面会有详解)。

​ 

​ 假如：切入点表达式改为DeptServiceImpl.list()，此时就代表仅仅只有list这一个方法是切入点。只有list()方法在运行的时候才会应用通知。

4. 切面：Aspect，描述通知与切入点的对应关系（通知+切入点）

​ 当通知和切入点结合在一起，就形成了一个切面。通过切面就能够描述当前aop程序需要针对于哪个原始方法，在什么时候执行什么样的操作。

​

​ 切面所在的类，我们一般称为切面类（被@Aspect注解标识的类）

5. 目标对象：Target，通知所应用的对象

​ 目标对象指的就是通知所应用的对象，我们就称之为目标对象。

​

AOP的核心概念我们介绍完毕之后，接下来我们再来分析一下我们所定义的通知是如何与目标对象结合在一起，对目标对象当中的方法进行功能增强的。

Spring的AOP底层是基于动态代理技术来实现的，也就是说在程序运行的时候，会自动的基于动态代理技术为目标对象生成一个对应的代理对象。在代理对象当中就会对目标对象当中的原始方法进行功能的增强。