Spring 事务隔离级别与传播行为：深度理解与实践

Spring 事务隔离级别与传播行为：深度理解与实践

各位看官，大家好！今天咱们聊聊Spring事务管理这块“硬骨头”，但别担心，我会尽量用“人话”把它掰开了、揉碎了，让大家彻底理解Spring事务的隔离级别和传播行为。

话说天下大事，分久必合，合久必分。数据库的世界里，事务也遵循着类似的哲学。多个事务并发执行时，难免会互相干扰，就像两个人在同一块画布上作画，稍不留神就会把对方的作品给毁了。为了解决这个问题，就有了“事务隔离级别”的概念，它就像一道屏障，隔离着不同的事务，让它们互不干扰。

而“事务传播行为”则更像是一种“团队合作”模式，它定义了当一个事务方法调用另一个事务方法时，事务该如何传递、如何处理。是“各自为战”还是“协同作战”，就看传播行为怎么设置了。

接下来，咱们就深入剖析一下这两个概念，并结合代码示例，让大家彻底掌握它们。

一、事务隔离级别：保护你的数据安全

事务隔离级别，顾名思义，就是定义事务之间相互隔离的程度。它就像一个安全等级，等级越高，隔离程度越高，但相应的性能开销也越大。Spring支持五种隔离级别，它们分别是：

隔离级别	描述	可能出现的问题
DEFAULT	使用底层数据库的默认隔离级别。	取决于数据库的默认设置。
READ_UNCOMMITTED	最低的隔离级别，允许读取尚未提交的数据。	脏读（Dirty Read），不可重复读（Non-repeatable Read），幻读（Phantom Read）
READ_COMMITTED	允许读取其他事务已经提交的数据，但禁止读取尚未提交的数据。	不可重复读（Non-repeatable Read），幻读（Phantom Read）
REPEATABLE_READ	保证在同一个事务中，多次读取同一数据的结果是一致的。	幻读（Phantom Read）
SERIALIZABLE	最高的隔离级别，强制事务串行执行，彻底避免并发问题。	性能开销大，并发度低。

1. DEFAULT：一切随缘

“DEFAULT”隔离级别就像一个“佛系青年”，一切都交给底层数据库自己决定。不同的数据库，默认的隔离级别可能不同，所以使用“DEFAULT”时，最好先了解一下你所使用的数据库的默认隔离级别。

2. READ_UNCOMMITTED：狂野西部

“READ_UNCOMMITTED”是最低的隔离级别，它允许一个事务读取另一个事务尚未提交的数据，这简直就是数据库世界的“狂野西部”。

• 脏读（Dirty Read）： 假设事务A修改了数据，但尚未提交，事务B读取了事务A修改后的数据，如果事务A最终回滚了，那么事务B读取到的就是“脏数据”。

代码示例：

@Service
public class AccountService {

    @Autowired
    private JdbcTemplate jdbcTemplate;

    @Transactional(isolation = Isolation.READ_UNCOMMITTED)
    public void transferMoneyDirtyRead(int accountId1, int accountId2, double amount) {
        // 事务A：修改账户1余额，但尚未提交
        jdbcTemplate.update("UPDATE account SET balance = balance - ? WHERE id = ?", amount, accountId1);

        // 模拟延迟，让事务B有机会读取未提交的数据
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // 事务A：回滚
        throw new RuntimeException("故意抛出异常，回滚事务");
    }

    @Transactional(isolation = Isolation.READ_UNCOMMITTED)
    public double getBalanceDirtyRead(int accountId) {
        // 事务B：读取账户1余额
        Double balance = jdbcTemplate.queryForObject("SELECT balance FROM account WHERE id = ?", Double.class, accountId);
        System.out.println("事务B读取到的余额：" + balance);
        return balance;
    }
}

在这个例子中，事务A（transferMoneyDirtyRead）修改了账户1的余额，但由于后面抛出了异常，事务最终会回滚。而事务B（getBalanceDirtyRead）在事务A尚未提交之前就读取了账户1的余额，因此它读取到的就是“脏数据”。

3. READ_COMMITTED：守望先锋

“READ_COMMITTED”隔离级别允许读取其他事务已经提交的数据，但禁止读取尚未提交的数据。它就像一个“守望先锋”，只允许读取已经确认的安全数据。大多数数据库的默认隔离级别都是“READ_COMMITTED”。

• 不可重复读（Non-repeatable Read）： 假设事务A多次读取同一数据，在事务A第一次读取数据之后，事务B修改了该数据并提交了，那么事务A再次读取该数据时，读取到的就是不同的数据。

代码示例：

@Service
public class AccountService {

    @Autowired
    private JdbcTemplate jdbcTemplate;

    @Transactional(isolation = Isolation.READ_COMMITTED)
    public void transferMoneyNonRepeatableRead(int accountId1, int accountId2, double amount) {
        // 事务A：读取账户1余额
        Double balance1 = jdbcTemplate.queryForObject("SELECT balance FROM account WHERE id = ?", Double.class, accountId1);
        System.out.println("事务A第一次读取到的余额：" + balance1);

        // 模拟延迟，让事务B有机会修改数据
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // 事务A：再次读取账户1余额
        Double balance2 = jdbcTemplate.queryForObject("SELECT balance FROM account WHERE id = ?", Double.class, accountId1);
        System.out.println("事务A第二次读取到的余额：" + balance2);
    }

    @Transactional(isolation = Isolation.READ_COMMITTED)
    public void updateBalanceNonRepeatableRead(int accountId, double amount) {
        // 事务B：修改账户1余额
        jdbcTemplate.update("UPDATE account SET balance = balance + ? WHERE id = ?", amount, accountId);
    }
}

在这个例子中，事务A（transferMoneyNonRepeatableRead）两次读取账户1的余额，在两次读取之间，事务B（updateBalanceNonRepeatableRead）修改了账户1的余额并提交了，因此事务A两次读取到的余额是不一样的。

4. REPEATABLE_READ：固若金汤

“REPEATABLE_READ”隔离级别保证在同一个事务中，多次读取同一数据的结果是一致的。它就像一座“固若金汤”的城堡，保证数据的稳定性和一致性。MySQL的默认隔离级别就是“REPEATABLE_READ”。

• 幻读（Phantom Read）： 假设事务A多次执行同一查询，在事务A第一次执行查询之后，事务B插入了一条符合事务A查询条件的新数据并提交了，那么事务A再次执行查询时，会发现多了一条之前不存在的数据，就像出现了“幻影”一样。

代码示例：

@Service
public class AccountService {

    @Autowired
    private JdbcTemplate jdbcTemplate;

    @Transactional(isolation = Isolation.REPEATABLE_READ)
    public void getAccountListPhantomRead(double minBalance) {
        // 事务A：第一次查询余额大于minBalance的账户数量
        int count1 = jdbcTemplate.queryForObject("SELECT COUNT(*) FROM account WHERE balance > ?", Integer.class, minBalance);
        System.out.println("事务A第一次查询到的账户数量：" + count1);

        // 模拟延迟，让事务B有机会插入新数据
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // 事务A：再次查询余额大于minBalance的账户数量
        int count2 = jdbcTemplate.queryForObject("SELECT COUNT(*) FROM account WHERE balance > ?", Integer.class, minBalance);
        System.out.println("事务A第二次查询到的账户数量：" + count2);
    }

    @Transactional(isolation = Isolation.REPEATABLE_READ)
    public void insertAccountPhantomRead(String name, double balance) {
        // 事务B：插入一条新账户
        jdbcTemplate.update("INSERT INTO account (name, balance) VALUES (?, ?)", name, balance);
    }
}

在这个例子中，事务A（getAccountListPhantomRead）两次查询余额大于minBalance的账户数量，在两次查询之间，事务B（insertAccountPhantomRead）插入了一条符合查询条件的新账户，因此事务A第二次查询到的账户数量比第一次多了一条。

5. SERIALIZABLE：绝对安全

“SERIALIZABLE”是最高的隔离级别，它强制事务串行执行，彻底避免并发问题。它就像一个“绝对安全”的保险箱，保证数据的绝对安全，但也牺牲了并发性能。

“SERIALIZABLE”隔离级别会锁定整个表，导致并发性能极低，所以一般情况下不建议使用。

如何选择合适的隔离级别？

选择合适的隔离级别需要在数据安全性和并发性能之间进行权衡。

• 对数据一致性要求不高，并发性能要求高： 可以选择“READ_UNCOMMITTED”或“READ_COMMITTED”。
• 对数据一致性有一定要求，但并发性能也很重要： 可以选择“REPEATABLE_READ”。
• 对数据一致性要求极高，可以牺牲一定的并发性能： 可以选择“SERIALIZABLE”。

一般来说，选择“REPEATABLE_READ”是一个比较折中的方案，既能保证一定的数据一致性，又能保持一定的并发性能。

二、事务传播行为：团队协作的艺术

事务传播行为定义了当一个事务方法调用另一个事务方法时，事务该如何传递、如何处理。它就像一种“团队协作”模式，决定了不同的事务方法是“各自为战”还是“协同作战”。Spring支持七种传播行为，它们分别是：

传播行为	描述
REQUIRED	如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
REQUIRES_NEW	无论当前是否存在事务，都创建一个新的事务。如果当前存在事务，则将当前事务挂起。
SUPPORTS	如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务方式执行。
NOT_SUPPORTED	以非事务方式执行操作，如果当前存在事务，则将当前事务挂起。
MANDATORY	必须在一个已存在的事务中执行，否则抛出异常。
NEVER	必须在一个非事务环境中执行，如果当前存在事务，则抛出异常。
NESTED	如果当前存在事务，则创建一个嵌套事务，该嵌套事务可以独立于外部事务进行提交或回滚。如果当前没有事务，则表现类似于REQUIRED。

1. REQUIRED：有难同当

“REQUIRED”是默认的传播行为。如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。它就像一个“有难同当”的朋友，无论你有没有麻烦，它都会和你一起承担。

代码示例：

@Service
public class AccountService {

    @Autowired
    private JdbcTemplate jdbcTemplate;

    @Transactional(propagation = Propagation.REQUIRED)
    public void transferMoneyRequired(int accountId1, int accountId2, double amount) {
        // 事务A：修改账户1余额
        jdbcTemplate.update("UPDATE account SET balance = balance - ? WHERE id = ?", amount, accountId1);

        // 调用另一个事务方法
        updateBalanceRequired(accountId2, amount);

        // 事务A：修改账户2余额
        //jdbcTemplate.update("UPDATE account SET balance = balance + ? WHERE id = ?", amount, accountId2);
    }

    @Transactional(propagation = Propagation.REQUIRED)
    public void updateBalanceRequired(int accountId, double amount) {
        // 事务B：修改账户2余额
        jdbcTemplate.update("UPDATE account SET balance = balance + ? WHERE id = ?", amount, accountId);

        // 模拟异常，导致事务回滚
        if (amount > 1000) {
            throw new RuntimeException("金额过大，拒绝转账");
        }
    }
}

在这个例子中，transferMoneyRequired方法和updateBalanceRequired方法都使用了“REQUIRED”传播行为。当transferMoneyRequired方法调用updateBalanceRequired方法时，由于transferMoneyRequired方法已经存在一个事务，所以updateBalanceRequired方法会加入到这个事务中。如果updateBalanceRequired方法抛出异常，导致事务回滚，那么transferMoneyRequired方法中的操作也会被回滚。

2. REQUIRES_NEW：另起炉灶

“REQUIRES_NEW”传播行为无论当前是否存在事务，都会创建一个新的事务。如果当前存在事务，则将当前事务挂起。它就像一个“另起炉灶”的人，无论你有没有饭吃，它都会自己开火做饭。

代码示例：

@Service
public class AccountService {

    @Autowired
    private JdbcTemplate jdbcTemplate;

    @Transactional(propagation = Propagation.REQUIRED)
    public void transferMoneyRequiresNew(int accountId1, int accountId2, double amount) {
        // 事务A：修改账户1余额
        jdbcTemplate.update("UPDATE account SET balance = balance - ? WHERE id = ?", amount, accountId1);

        // 调用另一个事务方法
        try {
            updateBalanceRequiresNew(accountId2, amount);
        } catch (Exception e) {
            System.out.println("updateBalanceRequiresNew 事务回滚");
        }

        // 事务A：修改账户2余额
        //jdbcTemplate.update("UPDATE account SET balance = balance + ? WHERE id = ?", amount, accountId2);
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void updateBalanceRequiresNew(int accountId, double amount) {
        // 事务B：修改账户2余额
        jdbcTemplate.update("UPDATE account SET balance = balance + ? WHERE id = ?", amount, accountId);

        // 模拟异常，导致事务回滚
        if (amount > 1000) {
            throw new RuntimeException("金额过大，拒绝转账");
        }
    }
}

在这个例子中，transferMoneyRequiresNew方法使用了“REQUIRED”传播行为，updateBalanceRequiresNew方法使用了“REQUIRES_NEW”传播行为。当transferMoneyRequiresNew方法调用updateBalanceRequiresNew方法时，updateBalanceRequiresNew方法会创建一个新的事务，并将transferMoneyRequiresNew方法的事务挂起。如果updateBalanceRequiresNew方法抛出异常，导致事务回滚，那么只会回滚updateBalanceRequiresNew方法中的操作，transferMoneyRequiresNew方法中的操作不会受到影响。

3. SUPPORTS：锦上添花

“SUPPORTS”传播行为如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务方式执行。它就像一个“锦上添花”的人，如果你需要帮助，它会尽力而为；如果你不需要帮助，它也不会强求。

4. NOT_SUPPORTED：事不关己

“NOT_SUPPORTED”传播行为以非事务方式执行操作，如果当前存在事务，则将当前事务挂起。它就像一个“事不关己”的人，无论你有没有麻烦，它都不会参与其中。

5. MANDATORY：必须帮忙

“MANDATORY”传播行为必须在一个已存在的事务中执行，否则抛出异常。它就像一个“必须帮忙”的朋友，如果你需要帮助，它必须挺身而出；如果你不需要帮助，它就会拒绝。

6. NEVER：禁止帮忙

“NEVER”传播行为必须在一个非事务环境中执行，如果当前存在事务，则抛出异常。它就像一个“禁止帮忙”的朋友，无论你需不需要帮助，它都不会参与其中。

7. NESTED：同生共死

“NESTED”传播行为如果当前存在事务，则创建一个嵌套事务，该嵌套事务可以独立于外部事务进行提交或回滚。如果当前没有事务，则表现类似于REQUIRED。它就像一个“同生共死”的兄弟，你们可以一起承担风险，也可以各自为战。

代码示例：

@Service
public class AccountService {

    @Autowired
    private JdbcTemplate jdbcTemplate;

    @Transactional(propagation = Propagation.REQUIRED)
    public void transferMoneyNested(int accountId1, int accountId2, double amount) {
        // 事务A：修改账户1余额
        jdbcTemplate.update("UPDATE account SET balance = balance - ? WHERE id = ?", amount, accountId1);

        // 调用另一个事务方法
        try {
            updateBalanceNested(accountId2, amount);
        } catch (Exception e) {
             System.out.println("updateBalanceNested 事务回滚");
        }

        // 事务A：修改账户2余额
        //jdbcTemplate.update("UPDATE account SET balance = balance + ? WHERE id = ?", amount, accountId2);
        //int i = 1/0;
    }

    @Transactional(propagation = Propagation.NESTED)
    public void updateBalanceNested(int accountId, double amount) {
        // 事务B：修改账户2余额
        jdbcTemplate.update("UPDATE account SET balance = balance + ? WHERE id = ?", amount, accountId);

        // 模拟异常，导致事务回滚
        if (amount > 1000) {
            throw new RuntimeException("金额过大，拒绝转账");
        }
    }
}

在这个例子中，transferMoneyNested方法使用了“REQUIRED”传播行为，updateBalanceNested方法使用了“NESTED”传播行为。当transferMoneyNested方法调用updateBalanceNested方法时，updateBalanceNested方法会创建一个嵌套事务。如果updateBalanceNested方法抛出异常，导致嵌套事务回滚，那么只会回滚updateBalanceNested方法中的操作，transferMoneyNested方法中的操作不会受到影响。但是如果transferMoneyNested方法抛出异常，导致外部事务回滚，那么updateBalanceNested方法中的操作也会被回滚。

如何选择合适的传播行为？

选择合适的传播行为需要根据具体的业务场景进行考虑。

• 需要保证所有操作要么全部成功，要么全部失败： 可以选择“REQUIRED”。
• 需要保证某个操作的独立性，即使其他操作失败，该操作也要成功： 可以选择“REQUIRES_NEW”。
• 某个操作可以参与到当前事务中，也可以独立执行： 可以选择“SUPPORTS”。
• 某个操作不需要参与到当前事务中，甚至希望当前没有事务： 可以选择“NOT_SUPPORTED”或“NEVER”。
• 某个操作必须在一个已存在的事务中执行： 可以选择“MANDATORY”。
• 某个操作需要一个可以独立于外部事务进行提交或回滚的事务： 可以选择“NESTED”。

三、总结

Spring事务的隔离级别和传播行为是事务管理中非常重要的两个概念。理解和掌握这两个概念，可以帮助我们更好地控制事务的边界，保证数据的安全性和一致性。

• 事务隔离级别 就像一道屏障，隔离着不同的事务，让它们互不干扰。
• 事务传播行为 则更像是一种“团队合作”模式，它定义了当一个事务方法调用另一个事务方法时，事务该如何传递、如何处理。

希望通过本文的讲解，大家能够对Spring事务的隔离级别和传播行为有一个更深入的理解，并在实际开发中灵活运用它们，编写出更加健壮和可靠的应用程序。

最后，记住一点：理论与实践相结合才是王道！多动手写代码，多思考，才能真正掌握这些知识。祝大家在编程的道路上越走越远！