别让 @Transactional 再次“失效”！Spring 事务管理的 5 大避坑指南-CSDN博客

本文链接：https://blog.csdn.net/dandandeshangni/article/details/149641092

在几乎所有的企业级 Java 应用中，数据的一致性都是至关重要的。Spring 框架提供的 @Transactional 注解，以其声明式的优雅，极大地简化了数据库事务管理。开发者只需在方法上添加一个注解，就能获得由 Spring 精心编排的事务支持。

然而，这份“简单”的背后，隐藏着基于 AOP 代理的复杂机制。如果对它的工作原理缺乏了解，就很容易陷入各种“事务失效”的陷阱——代码看起来没问题，但在特定场景下，事务的开启、提交、回滚却完全没有按预期工作。本文将深入剖析 @Transactional 的核心原理，并总结出 5 个最致命的陷阱及其规避方案。

`@Transactional` 的工作原理：AOP 代理的核心

要理解 @Transactional 为何会失效，首先必须明白它是如何工作的。

@Transactional 并非有什么语法魔法，它的核心是 Spring AOP (面向切面编程) 和 动态代理。当 Spring 容器启动时，它会为标注了 @Transactional 的 Bean 创建一个代理对象。当外部代码调用这个 Bean 的方法时，请求实际上会先经过这个代理对象。

可以把代理对象想象成一个“事务保安”：

1. 方法调用前 (保安检查): 代理对象开始一个数据库事务。
2. 执行真实方法: 代理对象调用你编写的原始业务逻辑方法。
3. 方法调用后 (保安决策):
- • 如果真实方法顺利执行完毕，代理对象就提交事务。
- • 如果真实方法抛出了特定的异常，代理对象就回滚事务。

理解了这一点，你就会明白，所有“事务失效”的问题，几乎都源于**“方法调用没有经过代理对象”或者“抛出的异常类型不对”**。

致命陷阱：为何我的事务没有回滚？

陷阱一：同类中的方法调用 (`this.` 调用)

这是最常见、也最隐蔽的陷阱。

错误示例：

@Service
publicclassOrderService {

    @Autowired
    private OrderRepository orderRepository;

    publicvoidcreateOrder(Order order) {
        // ... 一些前置操作 ...
        // 这个调用是通过 this.insertOrder()，直接访问了原始对象，绕过了代理
        this.insertOrder(order); 
    }

    @Transactional
    publicvoidinsertOrder(Order order) {
        orderRepository.save(order);
        // 假设这里抛出异常，事务也不会回滚
        if (true) {
            thrownewRuntimeException("DB operation failed");
        }
    }
}

原因分析： createOrder 方法本身没有 @Transactional 注解，所以调用它时不会经过代理。当它内部通过 this.insertOrder() 调用时，是直接在原始 OrderService 对象内部调用，完全绕过了 Spring 创建的代理对象。没有代理的介入，自然就没有事务的开启和回滚。

解决方案：

1. 注入自身 (Self-injection): 将 OrderService 自身注入到 OrderService 中，通过注入的代理对象来调用方法。

@Service
public class OrderService {
    @Autowired
    private OrderService self; // 注入自身代理

    public void createOrder(Order order) {
        self.insertOrder(order); // 通过代理调用
    }
    // ...
}

2. 移至不同类 (推荐): 将事务方法移动到另一个独立的 Bean 中，这是最清晰、最推荐的做法。

@Service
publicclassOrderCreator {
    @Transactional
    publicvoidinsertOrder(Order order) {
        // ...
    }
}

@Service
publicclassOrderService {
    @Autowired
    private OrderCreator orderCreator;
    
    publicvoidcreateOrder(Order order) {
        orderCreator.insertOrder(order); // 通过外部 Bean 的代理调用
    }
}

陷阱二：方法可见性问题 (非 `public` 方法)

由于动态代理的实现机制，@Transactional 注解必须应用于 public 方法上才能生效。如果应用在 protected、private 或包可见性的方法上，Spring 不会报错，但事务也不会起作用。

陷阱三：异常被 `try-catch` 捕获

如果事务方法内部捕获（catch）了异常，并且没有将异常重新抛出，那么 Spring 的事务代理就无法感知到异常的发生，从而会正常提交事务。

错误示例：

@Service
publicclassUserService {
    @Transactional
    publicvoidregister(User user) {
        try {
            userRepository.save(user);
            // 模拟一个运行时异常
            inti=1 / 0;
        } catch (Exception e) {
            // 异常被“吃掉”了，没有重新抛出
            System.err.println("注册时发生错误: " + e.getMessage());
            // 代理对象不知道发生了异常，事务会正常提交！
        }
    }
}

正确做法： 在 catch 块中处理完必要逻辑（如记录日志）后，必须将异常重新抛出，或者手动设置事务回滚。

陷阱四：错误的异常类型导致不回滚

默认情况下，Spring 只会对 RuntimeException (非受检异常) 和 Error 类型的异常进行事务回滚。 对于 Exception 及其子类（受检异常），它默认是不回滚的。

错误示例：

@Service
publicclassFileService {
    @Transactional
    publicvoidprocessFile(String path)throws IOException { // IOException 是受检异常
        // ... 文件读取和数据库写入 ...
        if (someCondition) {
            // 抛出一个受检异常
            thrownewIOException("File format error"); 
        }
        // 即使抛出 IOException，数据库的修改默认也不会回滚！
    }
}

解决方案： 使用 @Transactional 的 rollbackFor 或 noRollbackFor 属性来明确指定哪些异常应该（或不应该）触发回滚。

// 指定任何 Exception 及其子类都应触发回滚
@Transactional(rollbackFor = Exception.class)
public void processFile(String path) throws IOException {
    // ...
}

陷阱五：不正确的事务传播行为 (`propagation`)

@Transactional 的 propagation 属性定义了事务的传播行为。默认值是 REQUIRED，这在大多数情况下是适用的。但如果滥用 REQUIRES_NEW（总是开启一个全新的、独立的事务），可能会破坏业务逻辑的原子性，并对数据库连接造成不必要的压力。

经验法则： 除非你非常清楚地知道需要将一段逻辑放在一个完全独立的事务中（无论外部是否存在事务），否则请坚持使用默认的 REQUIRED。

生产级最佳实践

1. 注解位置： 通常应将 @Transactional 注解应用在**业务逻辑层（Service Layer）**的方法上，而不是数据访问层（DAO/Repository Layer）。Service 层的方法通常代表一个完整的业务操作单元。
2. 只读事务： 对于所有只读操作（如查询），强烈建议添加 readOnly = true 属性。这会向数据库和持久化框架提供一个性能优化的提示。
```
@Transactional(readOnly = true)
public List<User> listAllUsers() {
    return userRepository.findAll();
}
```
3. 粒度控制： 将注解应用于尽可能小范围的 public 方法上，而不是粗暴地放在整个类上，除非该类的所有公共方法都需要相同的事务配置。