@Transactional注解的作用是什么

<think>嗯，我现在需要了解Spring的@Transactional注解的作用和使用场景。首先，我记得这个注解是用来管理事务的，但具体是怎么工作的呢？根据用户提供的引用，特别是引用[1]，里面提到事务拦截器在方法执行前后进行拦截，获取注解的配置信息。所以，这个注解应该是通过AOP实现的，动态代理来处理事务的开启、提交或回滚。 然后，引用[3]给了一个例子，说明在方法上添加@Transactional后，如果有异常发生，数据会回滚。这说明它的主要功能是声明式事务管理，让开发者不用手动处理事务的复杂逻辑。但用户提供的引用里也提到了一些失效的场景，比如非public方法、传播属性设置错误、异常被捕获等。比如引用[2]里说，如果方法不是public的，事务就不会生效，因为动态代理无法应用到私有方法上。这点需要注意，我之前可能没注意到方法修饰符的影响。 再来看使用场景，引用[3]中的例子是在方法上使用，确保多个数据库操作要么全部成功，要么全部失败。比如保存两个用户，如果有异常就回滚。不过用户的问题可能还想知道其他使用场景，比如不同的传播行为。比如REQUIRED是默认的，如果当前有事务就加入，没有就新建。而SUPPORTS则是如果有事务就加入，没有就以非事务运行。这些传播行为在不同的业务需求下有不同的应用，需要根据具体情况选择。 另外，失效场景中的同一个类内调用问题，引用[4]提到，如果外围方法A调用内部方法B，而A没有注解，B有的话，事务不会生效。这是因为内部调用绕过了代理，直接调用了方法，导致AOP无法介入。这种情况下应该将方法B移到另一个类中，或者通过代理对象来调用，才能触发事务。 关于传播特性的不同值，引用[2]里详细列出了几种，比如REQUIRES_NEW会挂起当前事务，新建一个独立的事务。MANDATORY要求必须在已有事务中运行，否则抛出异常。这些不同的选项可以应对复杂的业务逻辑需求，比如需要独立事务或者必须存在事务的情况。 还有异常回滚的问题，默认情况下Spring只在抛出unchecked异常（RuntimeException和Error）时回滚。如果抛出的是检查型异常，比如IOException，默认不会回滚，需要显式设置rollbackFor属性。此外，如果在方法里捕获了异常但没有重新抛出，事务也不会回滚，必须处理异常或者标记回滚状态。 总结一下，@Transactional的作用是通过声明式事务简化管理，基于AOP实现，配置灵活，但需要注意方法可见性、传播设置、异常处理等问题，避免失效。使用场景包括需要事务管理的数据库操作，特别是多个操作需要原子性的情况，以及需要不同传播行为的复杂事务管理。</think>### Spring @Transactional 注解的作用及使用场景 #### 一、核心作用 1. **声明式事务管理** `@Transactional` 通过 AOP 动态代理实现事务的自动管理。在方法执行前开启事务，执行后根据结果提交或回滚，无需手动编写事务代码[^1][^3]。 2. **事务传播控制** 支持多种传播行为（如 `REQUIRED`、`SUPPORTS`、`REQUIRES_NEW`），用于定义事务的边界和嵌套逻辑[^2]。 3. **异常回滚配置** 默认对 `RuntimeException` 和 `Error` 回滚，可通过 `rollbackFor` 自定义触发回滚的异常类型[^2]。 --- #### 二、典型使用场景 1. **单方法事务** 在需要事务的 **public 方法** 上添加注解，确保多个数据库操作原子性。例如： ```java @Transactional public void transferMoney(Account from, Account to, double amount) { from.withdraw(amount); to.deposit(amount); } ``` 若 `withdraw()` 或 `deposit()` 抛出异常，所有操作均回滚[^3]。 2. **嵌套事务控制** 通过传播行为管理复杂事务： - **`REQUIRED`（默认）**：外层存在事务则加入，否则新建。 - **`REQUIRES_NEW`**：挂起当前事务，新建独立事务。 - **`MANDATORY`**：强制要求当前存在事务，否则抛出异常[^2]。 3. **分布式事务基础** 结合 JTA 或 Seata 等框架，支持跨多个数据源的事务协调（需额外配置）。 --- #### 三、常见失效场景及规避 1. **非 public 方法** AOP 代理无法增强私有方法，需确保方法为 `public`[^2]。 2. **同类内调用** 若方法 A（无事务）调用方法 B（有事务），事务不生效。 **解决**：通过代理对象调用（如注入自身 Bean 或使用 `@Autowired`）[^4]。 3. **异常处理不当** - 默认不捕获 `checked exception`，需通过 `@Transactional(rollbackFor = Exception.class)` 配置。 - 若异常被 `try-catch` 吞没，需手动标记回滚： ```java try { // 业务代码 } catch (Exception e) { TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); } ``` 4. **传播属性冲突** 错误设置 `propagation = NOT_SUPPORTED` 会导致事务挂起，需根据业务选择合适传播行为[^2]。 --- #### 四、配置示例 ```java @Service public class OrderService { @Autowired private PaymentService paymentService; // 嵌套事务：支付和日志记录使用独立事务 @Transactional(propagation = Propagation.REQUIRED) public void placeOrder(Order order) { saveOrder(order); paymentService.processPayment(order); // 内部使用 REQUIRES_NEW logOrderActivity(order); } @Transactional(propagation = Propagation.REQUIRES_NEW) private void logOrderActivity(Order order) { // 日志记录逻辑 } } ``` ---