为什么不推荐使用@Transactional声明事务而使用TransactionTemplate？

文
章
目
录

• 一、Spring事务管理的两种方式
• 二、@Transactional注解，真有那么完美吗？
• 三、TransactionTemplate编程式事务管理，好在哪？
• 四、两者对比，谁更胜一筹？
• 五、该怎么选择呢？
• 六、写在最后

在日常的Spring开发过程中，不少小伙伴应该都见过下面这样的代码：

@Transactional
public void saveUser(User user) {
    userRepository.save(user);
    log.info(\"User saved\");
}

就这么一个@Transactional注解，就能轻松开启事务，用起来确实方便。但大家有没有深入了解过它的工作原理呢？在一些复杂多变的业务场景里，@Transactional可不是最好的选择。今天咱就来唠唠Spring中的两种事务管理方式，再讲讲为啥不能总是依赖@Transactional。

一、Spring事务管理的两种方式

Spring主要提供了两种事务管理方式，它们各有特点和适用场景。

• 声明式事务管理（@Transactional）：这种方式就是在方法或者类上加上@Transactional注解，简单直接。比较适合用在业务逻辑简单、处于标准业务服务层的场景。比如说，一个普通的用户注册功能，只涉及到向数据库插入一条用户数据，用它就很合适。
• 编程式事务管理（TransactionTemplate）：它需要显式地调用模板来执行事务。在处理复杂逻辑、需要组合多个事务，或者对事务的可控性要求较高的场景中，它就能大显身手了。像涉及多个不同业务模块的数据操作，还可能需要根据不同情况决定是否回滚事务，这种情况用它就更靠谱。

二、@Transactional注解，真有那么完美吗？

先来看个示例代码：

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Transactional
    public void createUser(User user) {
        userRepository.save(user);
        // 模拟异常
        if (true) {
            throw new RuntimeException(\"模拟异常\");
        }
    }
}

这段代码里，createUser方法上加了@Transactional注解，看起来一切正常。但实际上，它存在不少潜在问题。

1. 内部方法调用无效：看下面这段代码：

@Service
public class OrderService {

    public void outerMethod() {
        innerTransactionalMethod(); // 无效！
    }

    @Transactional
    public void innerTransactionalMethod() {
        // 事务不会生效
    }
}

在OrderService类里，outerMethod调用了innerTransactionalMethod，虽然innerTransactionalMethod上加了@Transactional注解，但事务并不会生效。这是因为Spring的事务管理是基于代理实现的，内部方法调用不会经过代理，所以事务也就没法起作用了。
2. 默认异常行为不直观：再看这个例子：

@Transactional
public void updateUser() throws IOException {
    userRepository.save(user);
    throw new IOException(); // 不会回滚！
}

在updateUser方法里，执行了数据库保存操作后抛出了IOException，但默认情况下，这个事务不会回滚。因为@Transactional默认只对RuntimeException及其子类进行回滚，像IOException这种检查异常，需要额外配置才会回滚，这就很容易让人产生误解。
3. 不适用于异步/多线程环境：事务只在当前线程有效，如果在多线程环境下，比如使用线程池或者进行异步任务时，事务不会自动传播。这就可能导致数据不一致的问题，比如一个线程执行了部分业务操作，另一个线程也在同时操作相关数据，却不受事务控制。
4. 不适用于含远程调用的业务：

@Transactional
public void updateUser() throws IOException {
    userRepository.save(user);
    // 远程调用消息服务
    messageApi.sendMessage(user); //远程调用不受事务控制，可能导致事务超时或数据不一致
}

当方法中存在远程调用时，比如调用消息服务发送消息，远程调用部分不受事务控制。这可能会出现事务超时，或者因为远程调用成功但本地事务回滚，导致数据不一致的情况。

三、TransactionTemplate编程式事务管理，好在哪？

先看示例代码：

@Service
public class UserService {

    @Autowired
    private TransactionTemplate transactionTemplate;

    @Autowired
    private UserRepository userRepository;

    public void createUser(User user) {
        transactionTemplate.executeWithoutResult(status -> {
            try {
                userRepository.save(user);
                if (true) throw new RuntimeException(\"模拟异常\");
            } catch (Exception e) {
                status.setRollbackOnly();
                throw e;
            }
        });
    }
}

在这段代码里，通过TransactionTemplate来管理事务。它有不少优势：

• 事务边界明确：在代码里能很清楚地看到事务的开始和结束位置，不像@Transactional注解那样，事务范围不太直观。
• 控制更细粒度：可以在代码中灵活地控制事务的各种行为，比如捕获异常后手动设置回滚，根据不同的业务逻辑进行更细致的处理。
• 无代理问题：因为是通过编程方式管理事务，不存在像@Transactional内部方法调用无效的代理问题。
• 适用于嵌套事务和多线程环境：在处理嵌套事务时也很方便，并且在多线程环境下，只要合理编写代码，就能有效管理事务。

四、两者对比，谁更胜一筹？

为了让大家更清楚地了解@Transactional和TransactionTemplate的区别，咱们来做个对比：

从表格里可以看出，@Transactional使用起来确实简单方便，但在灵活性、异常控制等方面存在不足；而TransactionTemplate虽然代码量相对多一些，但在复杂业务场景下，优势就很明显了。

五、该怎么选择呢？

• 适合使用@Transactional的场景：业务逻辑比较简单，控制流程清晰，并且开发团队对它潜在的问题有足够的了解，能有效避免那些坑的情况下，可以使用@Transactional。
• 适合使用TransactionTemplate的场景：业务中存在复杂的事务逻辑，涉及多个事务的组合或嵌套调用，或者有内部方法调用、异步任务，对异常控制和事务边界要求较高时，TransactionTemplate就是更好的选择。

六、写在最后

虽然@Transactional注解看起来简洁优雅，但它背后隐藏了不少细节和容易踩的坑。在中大型项目或者业务复杂度高的系统里，这些隐藏的问题很可能导致意想不到的结果。相比之下，TransactionTemplate虽然代码多了点，但它明确可控，在团队协作、处理复杂流程时，更能保证代码的可读性。

咱们写代码，可不是代码越少越好，而是要让逻辑清晰易懂。当然啦，如果团队成员都能熟练掌握@Transactional，避免那些潜在问题，用它也没问题。但在大多数情况下，还是更推荐大家试试TransactionTemplate，体验更好！