SpringBoot事务注解@Transactional失效场景与解决方案_Java

开发中我们经常会用到 spring boot 的事务注解，为含有多种操作的方法添加事务，做到如果某一个环节出错，全部回滚的效果。但是在开发中可能会因为不了解事务机制，而导致我们的方法使用了 @transactional 注解但是没有生效的情况，下面就把这几种不能生效的情况整理一下。

一、非public方法（动态代理限制）

spring 的事务管理本质上是通过 aop 动态代理 实现的（jdk 动态代理或 cglib 代理）。

代理对象在调用目标方法时，会添加事务管理的逻辑（开启事务、提交/回滚事务）。

然而，动态代理只能代理 public 方法。

如果你将 @transactional 注解放在 protected、private 或默认（包级私有）方法上，spring 在创建代理时无法为这些方法添加事务增强逻辑。

当你通过代理对象调用这些非 public 方法时，事务相关的代码（如 begintransaction(), commit(), rollback()）不会被织入，因此事务管理完全失效。

所以，要确保所有需要事务管理的方法都是 public 的。这是 spring aop 代理机制的一个硬性限制。

二、自调用问题（类内部方法调用，不走代理）

这是 aop 代理机制带来的另一个典型问题。假设一个 service 类中有两个方法：

methoda()：没有 @transactional 注解。
methodb()：有 @transactional 注解。

如果你在 methoda() 内部直接调用 this.methodb()，那么你调用的是 service 类本身的 methoda()（this 指向目标对象本身）。methoda() 内部调用 this.methodb()，是目标对象内部的方法调用。

这个调用完全不经过为该 service 类生成的代理对象。

因为调用 methodb() 没有经过代理对象，所以代理对象上附加的事务拦截逻辑根本不会被执行。methodb() 虽然标注了 @transactional，但在此次调用中完全失效。

解决方案有以下几种：推荐重构代码。

方案一：注入自身代理对象

开启 exposeproxy：在配置类（如 @springbootapplication 主类）上添加 @enableaspectjautoproxy(exposeproxy = true)。

在需要自调用事务方法的地方获取代理对象：

((yourserviceclass) aopcontext.currentproxy()).methodb();

aopcontext.currentproxy() 获取到当前方法执行上下文中的代理对象（即被 spring aop 增强过的对象），通过这个代理对象调用 methodb()，就会走代理逻辑，事务拦截器生效。

这种方式不常用，会有缺点，引入了 spring aop 特定 api (aopcontext)，增加了代码耦合度。

方案二：重构代码（推荐）

将需要事务管理的业务逻辑 methodb() 抽取到另一个独立的 bean（如另一个 service）中。然后在原来的 methoda() 中注入并使用这个新的 bean 来调用 methodb()。这样调用自然通过代理对象进行。

这是更符合设计原则（单一职责、依赖注入）的做法，避免了自调用问题，也降低了耦合。

方案三：使用 applicationcontext 获取 bean

在类中注入 applicationcontext，然后通过 ctx.getbean(yourserviceclass.class).methodb() 来调用。这样获取到的是代理 bean，调用会走代理。

代码略显繁琐，并且也需要依赖 spring 容器。

三、异常类型不匹配（默认只回滚runtimeexception）

@transactional 注解的 rollbackfor 属性默认值是 runtimeexception 和 error。

当方法抛出 runtimeexception 或其子类（如 nullpointerexception, illegalargumentexception）时，spring 会回滚事务。
当方法抛出检查型异常（如 ioexception, sqlexception）时，spring 默认会提交事务！

如果你在一个事务方法中抛出了自定义的业务异常（继承自 exception 而非 runtimeexception），或者抛出了其他检查型异常，并且没有显式配置 rollbackfor，那么即使业务逻辑出错抛出了异常，spring 也会正常提交事务，导致数据不一致。

这时，我们要显式指定 rollbackfor：在 @transactional 注解中明确声明哪些异常需要触发回滚。

// 回滚所有 exception 和自定义异常
@transactional(rollbackfor = {exception.class, yourcustombusinessexception.class}) 
public void transactionalmethod() throws exception { ... }

或者修改默认行为（谨慎）：虽然不推荐，但可以通过修改 spring 的全局事务管理器配置来改变默认的回滚异常类型（例如改为回滚所有 throwable）。

但这样做风险较大，可能回滚不应该回滚的异常（如 outofmemoryerror）。

最佳实践还是根据具体业务在注解上显式配置 rollbackfor 和 norollbackfor。

四、多线程切换（事务连接绑定threadlocal）

spring 的事务管理核心是将数据库连接（connection）绑定到当前执行线程（thread）的 threadlocal 变量上。

一个事务从开始（begintransaction）到提交/回滚（commit/rollback）期间，所有数据库操作都使用这个绑定在当前线程 threadlocal 上的同一个 connection，以此保证 acid 特性。

如果你在一个事务方法内部启动了一个新线程（new thread()）或者使用线程池（如 @async）执行数据库操作，会出现以下情况：

新线程拥有自己独立的 threadlocal 存储。
新线程无法访问到原始事务线程绑定的 connection 对象。
新线程中的数据库操作会从连接池获取一个新的、独立的 connection。
这个新 connection 不参与原始事务，其操作会在自身 autocommit 模式下立即执行（通常是自动提交），与原始事务完全隔离。

新线程中的数据库操作成功与否不影响原始事务的提交或回滚，反之亦然。破坏了事务的原子性（atomicity）。原始事务回滚不会回滚新线程中的操作；新线程操作失败也不会导致原始事务回滚。

解决方案：处理多线程下的数据一致性非常复杂，没有银弹：

避免在事务方法内开启异步线程执行 db 操作：**这是最根本的预防措施。将需要在同一事务中完成的操作放在同一个线程内执行。
编程式事务管理：在新线程内部，使用 transactiontemplate 手动管理事务边界。但这只是让新线程内部操作具有事务性，无法与原始线程的事务合并成一个原子事务。
分布式事务：如果业务强要求跨线程的 acid，可能需要引入分布式事务管理器（如 seata, atomikos）来处理这种跨资源（不同线程可视为不同资源管理者）的场景，但代价高昂且复杂。
设计补偿机制：在业务层设计最终一致性方案（如 saga 模式），通过记录操作日志、发送消息、定时任务补偿等方式，在异步操作失败后尝试回滚或修正原始事务已提交的操作。这是更常见的处理异步事务一致性的实践。

五、错误传播行为（如：propagation_not_supported挂起事务）

@transactional 的 propagation 属性定义了当前方法的事务如何与已存在的事务进行交互。使用不当会导致事务行为不符合预期。

propagation_not_supported ：不支持事务。如果当前存在事务，则挂起（suspend）这个事务；然后以非事务方式执行当前方法。方法执行完毕后，之前挂起的事务恢复（resume）。

假设方法 outer() 开启了一个事务（propagation.required），在其内部调用 inner() 方法，而 inner() 被标注为 @transactional(propagation = propagation.not_supported)，当执行到 inner() 时：

系统检测到当前存在 outer() 开启的事务。
根据 not_supported 语义，挂起 outer() 的事务。
inner() 方法在无事务状态下执行（相当于 autocommit=true）。
inner() 方法执行完毕（无论成功失败，其操作已立即提交）。
恢复 outer() 的事务，继续执行 outer() 剩余代码。

结果是 inner() 方法中的数据库操作不受 outer() 事务控制。即使 outer() 最终因异常回滚，inner() 中已提交的操作不会被回滚！这通常不是开发者想要的效果，极易造成数据不一致。

其他易错传播行为：

propagation_never：要求不能存在事务。如果调用者在一个事务中调用了标记为 never 的方法，会直接抛出 illegaltransactionstateexception 异常。
propagation_supports：如果当前存在事务，就加入该事务；如果没有，就以非事务方式执行。关键点在于非事务方式。如果方法中有多个操作且需要原子性，而外部又恰好没有事务，这些操作就会各自独立提交。
propagation_requires_new：总是开启一个全新的、独立的事务。会挂起外部事务（如果存在）。新事务的提交/回滚与外部事务互不影响。注意： 这虽然创建了新事务，但不同于自调用失效，它是有效的（通过代理调用）。它的陷阱在于开发者可能误以为新事务是外部事务的一部分，其实它们是独立的。

解决方案：

深入理解传播行为： 务必清楚每种传播行为（required, requires_new, supports, mandatory, not_supported, never, nested）的精确语义。
谨慎选择传播行为： 默认使用 propagation.required 通常能满足大多数场景（加入现有事务，没有则新建）。只有在有明确且充分理由时才使用其他传播行为。
代码审查与测试： 对使用了非默认传播行为的代码进行重点审查，并通过单元测试、集成测试模拟各种调用链路，验证事务边界和回滚行为是否符合预期。特别注意跨方法、跨服务调用时的事务传播。