当前位置：首页 > news >正文

Spring 声明式事务万字详解（通俗易懂）

news 来源：原创 2025/6/23 6:19:42

Δ前言

一、声明式事务快速入门

1.为什么需要声明式事务？

2.定义：

3.应用实例：

二、声明式事务的传播机制

1.引出问题：

2.传播机制分类：

3.应用实例：

三、声明式事务的隔离机制

1.四种隔离级别：

2.应用实例：

3.事务超时回滚：

Δ总结

Δ前言

第七节内容，up主要和大家分享一下Spring 声明式事务相关的内容；包括声明式事务的快速入门，事务传播机制和隔离机制。
注意事项——①代码中的注释也很重要；②不要眼高手低，自己跟着敲一遍才真正有收获；③点击文章的侧边栏目录或者文章开头的目录可以进行跳转。
良工不示人以朴，up所有文章都会适时补充完善。大家如果有问题都可以在评论区进行交流或者私信up。感谢阅读！

一、声明式事务快速入门

1.为什么需要声明式事务？

传统的编程式事务（Programmatic Transaction）需要开发者手动编写代码来控制事务的开启、提交、回滚。
传统编程式事务，事务逻辑与业务代码耦合性高，且每个事务方法需重复编写 try-catch 和事务模板代码，造成代码冗余；修改事务逻辑需逐个方法调整，易出错，维护成本高。

2.定义：

声明式事务（Declarative Transaction）是 Spring 框架提供的一种 通过配置（而非代码）管理事务 的机制。开发者无需在业务代码中手动编写事务开启、提交或回滚逻辑，而是通过注解或 XML 定义事务规则，由 Spring 自动处理事务的完整生命周期。
与Spring 声明式事务相关的核心类，就在spring-tx-xxx.jar包下，如下图所示：

声明式事务的底层通过 动态代理 + AOP 拦截 实现，结合事务管理器和线程资源绑定，将事务逻辑与业务代码解耦。其核心思想是 “约定优于配置”，开发者只需关注业务逻辑，事务管理由框架自动完成。

3.应用实例：

需求：要求完成用户购买商品的业务逻辑处理，并正确地处理用户余额、商品库存的更新。（以下案例仅用于演示声明式事务，并无实际意义）
分析：
① 既然要求正确处理用户余额和商品库存的更新，所以数据库中肯定要有 用户账目表 和 商品库存表，而要想处理用户余额，必须得知道用户所购买的商品的价格，所以还需要一张 商品表，那么一共需要三张表。
② 假设以Commodity表示商品，我们需要在 CommodityDAOImpl 中组织SQL语句，CommodityDAOImpl中至少需要实现三种数据库操作——查询商品的价格、更新用户余额、更新商品库存。而在 CommodityServiceImpl 中我们要完成业务逻辑的处理，其实就是把DAO层定义的若干个方法进行灵活地组合，从而实现特定的业务逻辑（此处为购买商品的业务逻辑）。
实现：
首先，来创建 `user_account`, `commodities` , `inventory_report`三张表，SQL代码如下：

# 创建用户账目表
CREATE TABLE `user_account` (
		`user_id` INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
		`user_name` VARCHAR(64) NOT NULL DEFAULT '',
		`user_balance` DOUBLE NOT NULL DEFAULT 0.0
) CHARACTER SET utf8mb3 COLLATE utf8mb3_bin ENGINE INNODB;

INSERT INTO `user_account` 
		VALUES(NULL, 'Cyan', 500),(NULL, 'Five', 2000);

# 创建商品表
CREATE TABLE `commodities` (
		`c_id` INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
		`c_name` VARCHAR(64) NOT NULL DEFAULT '',
		`c_price` DOUBLE NOT NULL DEFAULT 0.0
) CHARACTER SET utf8mb3 COLLATE utf8mb3_bin ENGINE INNODB;

INSERT INTO `commodities`(`c_name`, `c_price`)
		VALUES('mini washing machine', 300.0),('lamp', 35.0),('keyboard', 150.0);
		
# 创建商品库存表
CREATE TABLE`inventory_report` (
		`ir_id` INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
		`ir_amount` INT UNSIGNED DEFAULT 0
) CHARACTER SET utf8mb3 COLLATE utf8mb3_bin ENGINE INNODB;

INSERT INTO `inventory_report`
		VALUES(NULL, 3), (NULL, 11), (NULL, 9);

创建后的三张表，如下图所示：（注意看清楚当前商品的库存和用户的余额）

接着，我们来编写CommodityDAOImpl类和 CommodityServiceImpl类，前者负责实现对上面三张表的操作，后者负责将DAO中的方法灵活组合，以实现购买商品的业务逻辑处理。
CommodityDAOImpl类代码如下：

package com.cyan.spring.dao;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Repository;

/**
 * @author : Cyan_RA9
 * @version : 22.0
 */
@Repository(value = "commodityDAO")
public class CommodityDAOImpl {
    //使用 @Autowired 进行自动装配
    @Autowired
    @Qualifier(value = "jdbcTemplate01")
    private JdbcTemplate jdbcTemplate;

    //根据 商品id 查询 商品价格
    public Float queryPriceById(Integer c_id) {
        String sql = "SELECT `c_price` FROM `commodities` WHERE `c_id` = ?";
        Float c_price = jdbcTemplate.queryForObject(sql, Float.class, c_id);
        return c_price;
    }

    //用户购买商品后，需要减少用户账目中的余额
    public void decreaseBalance(Integer user_id, Float c_price) {
        String sql = "UPDATE `user_account` " + "\n" +
                        "SET `user_balance` = `user_balance` - ? " + "\n" +
                        "Where `user_id` = ?";
        jdbcTemplate.update(sql, c_price, user_id);
    }

    //用户购买商品后，需要减少对应的商品库存量
    public void decreaseAmount(Integer c_id, int amount){
        String sql = "UPDATEX `inventory_report` " + "\n" +
                        "SET `ir_amount` = `ir_amount` - ? " + "\n" +
                        "Where `ir_id` = ?";
        jdbcTemplate.update(sql, amount , c_id);
    }
}

CommodityServiceImpl类，代码如下：

package com.cyan.spring.service;

import com.cyan.spring.dao.CommodityDAOImpl;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

/**
 * @author : Cyan_RA9
 * @version : 22.0
 */
@Service
public class CommodityServiceImpl {
    @Autowired
    private CommodityDAOImpl commodityDAO;

    /**
     * 该方法用于实现购买商品。
     * @param user_id：用户id
     * @param c_id：商品id
     * @param amount：购买数量
     */
    public void purchase(int user_id, int c_id, int amount) {
        //1.查询到商品价格
        Float c_price = commodityDAO.queryPriceById(c_id);

        //2.购买商品后，更新对应用户的账户余额
        commodityDAO.decreaseBalance(user_id, c_price * amount);

        //3.购买商品后，更新对应的商品库存
        commodityDAO.decreaseAmount(c_id, amount);
    }
}

别忘了最关键的一步，我们还没有配置xml！up以beans_tx.xml为例，代码如下：

<?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:contex="http://www.springframework.org/schema/context" xmlns:tx="http://www.springframework.org/schema/tx"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context https://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd">

    <!-- 配置扫面注解的包 -->
    <contex:component-scan base-package="com.cyan.spring.dao"/>
    <contex:component-scan base-package="com.cyan.spring.service"/>

    <!-- 配置启动基于注解的声明式事务 -->
    <!-- 注意一定要选择 springframework.org/schema/tx 下的tx命名空间 -->
    <tx:annotation-driven transaction-manager="dataSourceTransactionManager01"/>

    <!-- 配置properties文件 -->
    <contex:property-placeholder location="classpath:druid.properties"/>
    <!-- 配置数据源对象 -->
    <bean class="com.alibaba.druid.pool.DruidDataSource" id="dataSource01">
        <property name="driverClassName" value="${driverClassName}"/>
        <property name="url" value="${url}"/>
        <property name="username" value="${jdbc.username}"/>
        <property name="password" value="${jdbc.password}"/>
    </bean>
    <!-- 配置JdbcTemplate对象 -->
    <bean class="org.springframework.jdbc.core.JdbcTemplate" id="jdbcTemplate01">
        <property name="dataSource" ref="dataSource01"/>
    </bean>

    <!-- 配置事务管理器对象 -->
    <!--
        1.DataSourceTransactionManager实例，用于进行事务管理。
        2.一定要配置数据源属性，并且配置的数据源属性要和使用的jdbcTemplate配置的数据源一致。
    -->
    <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager"
            id="dataSourceTransactionManager01">
        <constructor-arg name="dataSource" ref="dataSource01"/>
    </bean>
</beans>

最后，up以TxTest类为测试类，令用户Five尝试购买两台迷你洗衣机，代码如下：

package com.cyan.spring.test;

import com.cyan.spring.service.CommodityServiceImpl;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

/**
 * @author : Cyan_RA9
 * @version : 22.0
 */
public class TxTest {
    @Test
    public void testPurchase() {
        //1.获得容器对象
        ApplicationContext ioc = new ClassPathXmlApplicationContext("beans_tx.xml");
        
        //2.根据容器对象获得CommodityServiceImpl对象
        CommodityServiceImpl commodityServiceImpl = (CommodityServiceImpl) ioc.getBean("commodityServiceImpl");

        //3.根据获得的CommodityServiceImpl 调用业务层方法
            /*
                id = 2的用户（即Five用户，初始余额是2000块），购买了 2件 id = 1的商品（即迷你洗衣机）
             */
        commodityServiceImpl.purchase(2, 1, 2);
    }
}

运行结果如下：

可能这时候就要有p小将（personable小将，指风度翩翩的人！）要说理了——啥玩意儿啊？写牛魔一大堆结果跑都跑不起来？👴要看的声明式事务搁哪儿呢？

p小将你先别急，注意看报错信息，是“bad SQL grammar”，意思就是我们的SQL语句语法错误，很快我们找到，是CommodityDAOImpl类中的 decreaseAmount方法出错了，如下图所示：

其实up这里是 故意写错 的，那为什么要故意写错呢？——就是为了看看没有事务支持的后果。请注意，我们这时候是没有开启“声明式事务”的（因为压根就没有用声明式事务的注解），那么我们来看一下数据库中 商品库存表 和 用户账目表 的数据变化情况，如下图所示：（左边是用户帐目表，右边是商品库存表）

可以看到，在没有事务的支持下，这种错误造成的后果就是——商品发不出去（库存没有减少），而用户的余额被白白扣掉了！

下面我们引入声明式事务！其实只要在 purchase(int, int, int) 方法上面加上一个 @Transactional 即可，如下图所示：

这时候如果我们再次运行TxTest测试类，会发现数据库中的数据没有变化，如下GIF图演示：

可以看到，有了声明式事务的加持后，即便用于更新商品库存的SQL语句出错，但是由于事务本身的 原子性，事务中用于操作数据库的一组DML（Data Manipulation Language) 要么全部成功，要么全部失败（全部失败指的是无效），也就不会造成数据更新不完整的后果。

好的，up现在将之前故意写错的SQL语句更改过来，如下图所示：

然后我们重新进行测试（现在可是已经配置了声明式事务噢！），测试方法代码如下：

    @Test
    public void testPurchase() {
        //1.获得容器对象
        ApplicationContext ioc = new ClassPathXmlApplicationContext("beans_tx.xml");

        //2.根据容器对象获得CommodityServiceImpl对象
        CommodityServiceImpl commodityServiceImpl = (CommodityServiceImpl) ioc.getBean("commodityServiceImpl");

        //3.根据获得的CommodityServiceImpl 调用业务层方法
            /*
                user_id = 1的用户（即Cyan用户，初始余额是500块），购买了 2件 c_id = 2的商品（即lamp，台灯）
             */
        commodityServiceImpl.purchase(1, 2, 2);
    }

运行结果：

可以看到，在事务支持下，正确的数据库操作成功执行！

二、声明式事务的传播机制

1.引出问题：

如果一个事务中包含了其他的事务（例如，一个启动了声明式事务的方法中调用了其他方法，而被调用的方法本身也配置了声明式事务），那么该如何控制事务呢？

2.传播机制分类：

如下表所示：(尤其注意前两种方式)

传播属性	描述
REQUIRED [默认]	如果有事务在运行，当前的方法就在这个事务内运行，否则，就启动一个新的事务，并在它自己的事务内运行
REQUIRES_NEW	当前的方法必须启动新事务，并在它自己的事务内运行。如果有事务正在运行，应该将它挂起
SUPPORTS	如果有事务在运行，当前的方法就在这个事务内运行。否则它可以不运行在事务中
NOT_SUPPORTED	当前的方法不应该运行在事务中。如果有运行的事务，将它挂起
MANDATORY	当前的方法必须运行在事务内部，如果没有正在运行的事务，就抛出异常
NEVER	当前的方法不应该运行在事务中。如果有运行的事务，就抛出异常
NESTED	如果有事务在运行，当前的方法就应该在这个事务的嵌套事务内运行。否则，就启动一个新的事务，并在它自己的事务内运行

@Transactional 中的propagation元素，默认传播机制是REQUIRED，如下图所示：

我们下面来看一个演示案例。

3.应用实例：

需求：不同用户购买商品，要调用不同的方法。例如Cyan用户购买商品要调用f1()方法，Five用户购买商品要调用f2()方法。

在上文“声明式事务快速入门”中，我们在 CommodityDAOImpl类 定义了三个方法——queryPriceById, decreaseBalance 和 decreaseAmount，现在我们在这个类新增一个方法，叫做decreaseAmountWrongVersion（见名知意，这个方法无法正确执行），代码如下：

    //一个故意写错的 用于更新商品库存量 的方法
    public void decreaseAmountWrongVersion(Integer c_id, int amount){
        String sql = "UPDATEXXXXX `inventory_report` " + "\n" +
                "SET `ir_amount` = `ir_amount` - ? " + "\n" +
                "Where `ir_id` = ?";
        jdbcTemplate.update(sql, amount , c_id);
    }

同样地，我们在 CommodityServiceImpl类 中，也新增一个 “故意写错” 的方法，代码如下：

    /**
     * 这个方法是错误的，无法购买成功。
     */
    @Transactional
    public void purchaseWrongVersion(int user_id, int c_id, int amount) {
        Float c_price = commodityDAO.queryPriceById(c_id);

        commodityDAO.decreaseBalance(user_id, c_price * amount);

        //PS: decreaseAmountWrongVersion 这个方法是错误滴！！！
        commodityDAO.decreaseAmountWrongVersion(c_id, amount);
    }

这样在CommodityServiceImpl类中，就有两个用于购买的方法了，且这两个方法都用了 @Transactional 修饰，如下图所示：

好的，接下来我们还需要一个再来建 TxTestServiceImpl类，在这个类中我们要编写一个同样使用 @Transactional 修饰的方法，并在该方法中调用上图中的两个方法。TxTestServiceImpl类代码如下：

package com.cyan.spring.service;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

/**
 * @author : Cyan_RA9
 * @version : 22.0
 */
@Service
public class TxTestServiceImpl {
    @Autowired
    @Qualifier(value = "commodityServiceImpl")
    CommodityServiceImpl commodityService;

    /**
     * 注意，外层方法 doublePurchase 本身，也使用了 @Transactional 修饰。
     * 即调用者 doublePurchase 本身，亦是一个事务。
     */
    @Transactional
    public void doublePurchase() {
        // user_id = 1 的用户（Cyan）购买 1件 c_id = 2（lamp）的商品
        commodityService.purchase(1, 2, 1);

        // user_id = 2 的用户（Five）购买 2件 c_id = 3（keyboard）的商品
        commodityService.purchaseWrongVersion(2, 3, 2);
    }
}

注意，由于 @Transactional 启用的声明式事务，默认传播机制是REQUIRED，因此虽然 doublePurchase()方法 中调用的两个内层方法也都开启了声明式事务，但是都要算在外层方法的事务中，也就是仅仅有一个事务在进行，只要其中有一条DML失效，那么整个事务的操作全部作废。So，现在的这个 doublePurchase() 方法是一定执行失败的！

好嘞，这时候为了验证事务传播机制，最后就需要一个测试方法啦~。代码如下：

    @Test
    public void testAffairPropagation() {
        ApplicationContext ioc = new ClassPathXmlApplicationContext("beans_tx.xml");

        TxTestServiceImpl txTestService = ioc.getBean(TxTestServiceImpl.class);
        
        txTestService.doublePurchase();
    }

先不急着运行，我们先来瞄一眼数据库中商品库存表 和 用户帐目表的情况，如下图所示：（左边是商品库存表，右边是用户帐目表）

运行测试方式，并查看数据库中商品库存表 和 用户帐目表的数据变化情况，如下GIF图所示：

可以看到，商品库存和用户余额都没有减少！这就是默认传播属性REQUIRED的机制。

还没完！下面我们把内层两个事务的 propagation属性 全部换成REQUIRED_NEW，如下图所示：

那根据上面表格中对REQUIRED_NEW的解释，此时内外层的事务是相互独立的呀！所以不难猜到，成功的事务将正确提交且无法被回滚，而失败的事务仍然会立即回滚。下面我们重新运行测试方法，如下图所示：

这个时候我们再去查看数据库中的商品库存表 和 用户帐目表的情况，如下图所示：（左边是商品库存表，右边是用户帐目表）

由此可知——
① 内层成功的事务在执行完毕后，会立即提交其独立事务，且已提交的事务无法回滚，即使外层事务后续失败。
② 内层失败的事务在抛出异常后，其独立事务会立即回滚，且异常会向上传播到外层事务，导致外层事务也回滚（除非外层捕获并处理异常）。
③ 外层事务回滚仅影响其自身的操作（如果有），不影响已提交的内层的成功执行的事务，即外层事务的回滚不会撤销已提交的内层的 REQUIRES_NEW 事务，因为它们是相互独立的。

三、声明式事务的隔离机制

1.四种隔离级别：

up之前在 “MySQL——事务机制与隔离机制”一文中，已经讲过了MySQL的四种隔离级别 和 脏读、幻读、不可重复读的定义，此处不再赘述，但up还是用表格来带大家简单回顾一下四种隔离级别，如下表所示：

MySQL隔离级别（4种）	脏读	幻读	不可重复读	加锁读
Read Uncommitted:读未提交	√	√	√	No
Read committed:读已提交	×	√	√	No
Repeatable Read:可重复读（默认）	×	×	×	No
Serializable:串行化（隔离级别最高）	×	×	×	Yes

2.应用实例：

需求：连续两次查询同一商品的价格，但在查询第一次商品后，尝试更改事务的隔离机制，并测试两次查询的结果是否一致。

实现：我们在 CommodityServiceImpl类 中新增一个方法用于实现连续两次查询，queryTwice方法代码如下：(设置断点)

    @Transactional
    public void queryTwice(int c_id) {
        Float priceV1 = commodityDAO.queryPriceById(c_id);
        System.out.println("第一次查询得到的价格为：" + priceV1);

        Float priceV2 = commodityDAO.queryPriceById(c_id);
        System.out.println("第二次查询得到的价格为：" + priceV2);
    }

并且，我们要在第二次的查询语句那一行，设置一个断点，因为我们要通过Debug来进行测试。如下图所示：

注意，此时我们并没有为 @Transactional 设置隔离级别，那么它就是默认的Repeatable Read，在这种隔离级别下，事务可以读到启动事务时刻数据库中的数据，并且不会被其他事务所进行的DML操作所影响。

好嘞，最后还需要一个测试方法来验证我们的结论，代码如下：

    @Test
    public void testIsolationMechanisms() {
        ApplicationContext ioc = new ClassPathXmlApplicationContext("beans_tx.xml");

        CommodityServiceImpl commodityService = ioc.getBean(CommodityServiceImpl.class);

        commodityService.queryTwice(3);
    }

我们对这个方法进行Debug，如下图所示：

可以看到，第一次查询的价格是150，并且程序现在卡在了断点处。
趁它卡住，我们悄咪咪去Navicat中修改id为3的商品的价格，如下图所示：

注意，由于up在修改语句时并没有开启新的事务，所以默认是直接提交的。接下来我们让程序直接跳转到下一个断点，如下图所示：

嗯？明明keyboard的价格已经被修改成了15，但是第二次查询却还是原来修改之前的150，这就是默认隔离机制——Repeatable Read！

好，接下来up将事务的隔离机制改为Read Committed，如下图所示：

然后进行同样的操作，先Debug，令程序卡在第一个断点，如下图所示：

然后去Navicat中悄咪咪修改价格，如下图所示：

让程序运行到下一个断点，如下图所示：

喏，还真不一样了，这就是 Read Commmitted 啦！

3.事务超时回滚：

事务超时回滚，是指如果一个事务执行的时间超过了某个时间限制，就让该事务回滚；我们可以通过 @Transactional 的timeout元素来设置超时时间。下面来看一个演示案例：

需求：测试事务超时回滚。
实现：在 CommodityServiceImpl类 中新定义一个 purchaseEX方法，代码如下：

    @Transactional(timeout = 3)
    /*
        timeout = 3 表示如果事务的执行时间超过了3秒，就进行回滚。
        若没有设置timeout元素，默认就是-1，表示使用数据库默认的事务超时时间，或者不支持超时回滚。
     */
    public void purchaseEX(int user_id, int c_id, int amount) {
        //1.查询到商品价格
        Float c_price = commodityDAO.queryPriceById(c_id);

        //2.购买商品后，更新对应用户的账户余额
        commodityDAO.decreaseBalance(user_id, c_price * amount);

        System.out.println("================ 4s > 3s =================");
        try {
            Thread.sleep(4000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("================ 超时了，回滚！ =================");

        //3.购买商品后，更新对应的商品库存
        commodityDAO.decreaseAmount(c_id, amount);
        System.out.println("👴购买成功🌶!");
    }

然后还是在测试类新建一个测试方法，代码如下：

    @Test
    public void testTimeout() {
        ApplicationContext ioc = new ClassPathXmlApplicationContext("beans_tx.xml");

        CommodityServiceImpl commodityService = ioc.getBean(CommodityServiceImpl.class);

        /*
            id为2的用户(Five) 购买1件 id为1的商品(mini washing machine)
         */
        commodityService.purchaseEX(2, 1, 1);
    }

在运行测试方法之前呢，我们先来瞄一眼数据库中商品库存表 和 用户帐目表的情况，如下图所示：（左边是商品库存表，右边是用户帐目表）

运行结果如下：

数据库有变化吗？如下图所示:

压根儿没变！看来事务确实超时回滚了！
为了确认事务超时回滚机制，我们把用于线程休眠的代码注释掉，然后重新运行测试方法，并查看数据库中商品库存表和用户帐目表的数据变化情况，如下GIF图所示：

可以看到，在事务未超时的情况下，数据都被正确地更新！

Δ总结

🆗，以上就是Spring系列博文第七小节的全部内容了。
总结一下，我们先是用一个详细的入门实例，了解了声明式事务的概念和使用，很明显地，我们可以感受到，声明式事务相比传统编程式事务最大的优点就是省事儿，不用写那么多重复的代码了，加两个注解统统搞定。之后，我们又一起学习了事务的传播机制和隔离机制，其实部分内容up在 MySQL系列也分享过了，大家有兴趣可以去看看噢~。
另外，之后up还会带大家深入分析Spring的底层源码，并且还会和大家一起手动实现Spring底层机制，敬请期待~❀。
下一节内容——暂时无了哈哈，Spring系列暂时告一段落，大家拜拜，感谢阅读！

System.out.println("END---------------------------------------------------------");