SpringBoot使用@Transactional事务失效原因及解决办法汇总

Java技术 潘老师 8个月前 (08-14) 644 ℃ (0) 扫码查看

1.概述

本文将探讨在日常Java项目业务开发中,对于@Transactional声明式事务在何种情形下可能失效,同时分析导致其失效的根本原因,以此来协助开发者避免在实际应用中遭遇类似问题。

众所周知,Spring所提供的声明式事务功能为事务配置带来了极大的便利。在Spring Boot的智能配置的辅助下,许多Spring Boot项目只需在方法上添加@Transactional注解,即可方便地启用方法级的事务配置。当然,对于后端开发人员而言,对于数据库事务的概念并不会感到陌生。他们了解到,当需要保证多个数据库操作要么全部成功,要么全部失败时,就必须依赖数据库事务来确保这些操作的一致性和原子性。

如下所示:

    @Override
    @Transactional(rollbackFor = Exception.class)
    public void addUser(UserParam param) {
        User user = PtcBeanUtils.copy(param, User.class);
        userDAO.insert(user);
        if (!CollectionUtils.isEmpty(param.getRoleIds())) {
            userRoleService.addUserRole(user.getId(), param.getRoleIds());
        }
    }

在新增用户的同时,还需要为其分配相应的用户角色。这里,我们运用@Transactional来确保事务的一致性。然而,许多开发者通常仅局限于在方法上简单地添加@Transactional注解,以为这样就可以高枕无忧,不必过多关注事务是否真正有效,以及在出错情况下是否能够正确地回滚事务。他们也不会考虑在复杂的业务代码中,涉及多个子业务逻辑的情况下,应如何正确处理事务。

虽然事务没有得到适当处理通常不会过于影响正常流程,且很难在测试阶段被察觉。然而,一旦系统变得越来越复杂,承受的压力逐渐加大,就会导致大量数据不一致的问题。随之而来的,是大量人工干预以检查和修复数据。

正是由于声明式事务@Transactional使用起来简单,许多开发者常常忽略了其中的细节。然而,实际上@Transactional涉及的细节非常多,可以说是一个充满细节的领域。如果不慎忽略这些细节,就可能会掉入陷阱。在本文中,我们将深入了解@Transactional的使用细节,填平这些潜在的坑。

2.@Transactional

话不多说,先看看该注解定义

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional {
​
  @AliasFor("transactionManager")
  String value() default "";
​
  @AliasFor("value")
  String transactionManager() default "";
​
  Propagation propagation() default Propagation.REQUIRED;
​
  Isolation isolation() default Isolation.DEFAULT;
​
  int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;
​
  boolean readOnly() default false;
​
  Class extends Throwable>[] rollbackFor() default {};
​
  String[] rollbackForClassName() default {};
​
  Class extends Throwable>[] noRollbackFor() default {};
​
  String[] noRollbackForClassName() default {};
​
}

从上面看出@Transactional既可以作用于类上,也可以作用于方法上,作用于类: 表示所有该类的**public**方法都配置相同的事务属性信息。接下来再看看其属性:

propagation

设置事务的传播行为,主要解决是A方法调用B方法时,事务的传播方式问题的,默认值为 Propagation.REQUIRED,其他属性值信息如下:

事务传播行为 解释
REQUIRED(默认值) A调用B,B需要事务,如果A有事务B就加入A的事务中,如果A没有事务,B就自己创建一个事务
REQUIRED_NEW A调用B,B需要新事务,如果A有事务就挂起,B自己创建一个新的事务
SUPPORTS A调用B,B有无事务无所谓,A有事务就加入到A事务中,A无事务B就以非事务方式执行
NOT_SUPPORTS A调用B,B以无事务方式执行,A如有事务则挂起
NEVER A调用B,B以无事务方式执行,A如有事务则抛出异常
MANDATORY A调用B,B要加入A的事务中,如果A无事务就抛出异常
NESTED A调用B,B创建一个新事务,A有事务就作为嵌套事务存在,A没事务就以创建的新事务执行

isolation

事务的隔离级别,默认值为 Isolation.DEFAULT。隔离级别的设定对于处理事务并发带来的脏读、不可重复读以及幻读/虚读等三大问题具有重要意义。通过明确规定事务的隔离级别,能够有效防范并发问题的产生。在实践中,常常会选择使用READ_COMMITTED和REPEATABLE_READ这两种常见的隔离级别。

isolation属性 解释
DEFAULT 默认隔离级别,取决于当前数据库隔离级别,例如MySQL默认隔离级别是REPEATABLE_READ
READ_UNCOMMITTED A事务可以读取到B事务尚未提交的事务记录,不能解决任何并发问题,安全性最低,性能最高
READ_COMMITTED A事务只能读取到其他事务已经提交的记录,不能读取到未提交的记录。可以解决脏读问题,但是不能解决不可重复读和幻读
REPEATABLE_READ A事务多次从数据库读取某条记录结果一致,可以解决不可重复读,不可以解决幻读
SERIALIZABLE 串行化,可以解决任何并发问题,安全性最高,但是性能最低

timeout

事务的超时时间,默认值为 -1。如果超过该时间限制但事务还没有完成,则自动回滚事务。

readOnly

指定事务是否为只读事务,默认值为 false;为了忽略那些不需要事务的方法,比如读取数据,可以设置 read-only 为 true。

rollbackFor

用于指定能够触发事务回滚的异常类型,可以指定多个异常类型。

noRollbackFor

抛出指定的异常类型,不回滚事务,也可以指定多个异常类型。

3.@Transactional失效场景、原因及修正方式

3.1 同一个类中的方法通过this调用导致失效

    public void addUser(UserParam param) {
        User user = PtcBeanUtils.copy(param, User.class);
        // 新增用户
        userDAO.insert(user);
        // 添加用户角色
        this.addUserRole(user.getId(), param.getRoleIds());
        log.info("执行结束了");
    }
​
    @Transactional(rollbackFor = Exception.class)
    public void addUserRole(Long userId, List roleIds) {
        if (CollectionUtils.isEmpty(roleIds)) {
            return;
        }
        ListuserRoles = new ArrayList();
        roleIds.forEach(roleId -> {
            UserRole userRole = new UserRole();
            userRole.setUserId(userId);
            userRole.setRoleId(roleId);
            userRoles.add(userRole);
        });
        userRoleDAO.insertBatch(userRoles);
        throw new RuntimeException("发生异常咯");
    }

在执行#addUser()方法时,可能会观察到事务控制失效的情况,即使出现异常,事务未能正确回滚,导致用户和角色绑定的数据仍然被成功插入。

在这里,我提供了一个关于@Transactional生效的原则,即必须通过代理过的类从外部调用目标方法才能使事务生效。

Spring采用AOP技术对方法进行增强,以实现事务控制。在调用被增强过的方法时,必然是通过代理对象进行的调用。然而,在这里,使用了关键字”this”引用的是原生对象,而不是代理对象。因此,事务控制并不会生效。

要进行修正,有以下两种方式:

  1. 将”this”替换为代理的userService。你可以通过自己注入自己(使用@Resource注解),或者直接在Spring容器中获取userService这个bean。这样做可以确保你调用的是代理对象,从而实现事务控制。
  2. 给#addUser()方法添加事务注解@Transactional(rollbackFor = Exception.class)。虽然在你的描述中未明确提到,但从内容中可以看出,#addUser()方法涉及到数据库事务操作,因此本来就应该开启事务。尽管为了演示失效情况,你未在该方法上添加事务注解,但实际应用中应该加上。不过需要注意,如果#addUser()方法只涉及判断和逻辑处理,不涉及数据库事务操作,这种解决方式可能不太适合。而且,如果没有正确处理异常,即使事务生效,也不能保证一定能够回滚。

3.2 异常被catch捕获导致@Transactional失效

如下所示:

    @Transactional(rollbackFor = Exception.class)
    public void addUser(UserParam param) {
        try {
            User user = PtcBeanUtils.copy(param, User.class);
            // 完成一些逻辑处理
          
            .......
              
            // 添加用户角色
            this.addUserRole(user.getId(), param.getRoleIds());
            log.info("执行结束了");
        } catch (Exception e) {
            log.error(e.getMessage());
        }
    }
​
    @Transactional(rollbackFor = Exception.class)
    public void addUserRole(Long userId, List roleIds) {
        if (CollectionUtils.isEmpty(roleIds)) {
            return;
        }
        List userRoles = new ArrayList();
        roleIds.forEach(roleId -> {
            UserRole userRole = new UserRole();
            userRole.setUserId(userId);
            userRole.setRoleId(roleId);
            userRoles.add(userRole);
        });
        userRoleDAO.insertBatch(userRoles);
        throw new RuntimeException("发生异常咯");
    }

@Transactional第二个生效原则涉及到事务的回滚机制:只有在异常传播到标记了 @Transactional 注解的方法之外时,事务才会执行回滚操作。之前我们曾经总结过基于AOP的事务控制实现原理,提及了Spring的 TransactionAspectSupport 类中的 invokeWithinTransaction 方法。

这个方法内部实现了事务的逻辑处理。从中可以看出,只有当捕获到异常后,才会执行后续的事务回滚操作。

  protected Object invokeWithinTransaction(Method method, @Nullable Class> targetClass,
      final InvocationCallback invocation) throws Throwable {
      
      ......
        
      try {
        // This is an around advice: Invoke the next interceptor in the chain.
        // This will normally result in a target object being invoked.
        retVal = invocation.proceedWithInvocation();
      }
      catch (Throwable ex) {
        // target invocation exception
        // 捕获到异常,进行回滚操作,如果我们在业务方法已经捕获掉异常,这里就捕获不到了,自然就不会回滚了
        completeTransactionAfterThrowing(txInfo, ex);
        throw ex;
      }
      finally {
        cleanupTransactionInfo(txInfo);
      }
    
      ......
        
      return result;
    }
  }

可以观察到,仅当检测到异常存在时,才会触发回滚操作。如果在业务方法内部已经捕获了异常并进行了处理,那么在这个层次就无法再次捕获到异常,因此自然也就无法触发回滚机制。

改进方式:关键在于对异常的捕获要更加精细和局部化,避免一概而论地将整个方法的代码逻辑都包裹在异常处理之中,这样可以将异常抛至更上一层。这样的处理方式有助于提升代码的可维护性和异常处理的准确性。

3.3 @Transactional 属性 rollbackFor 设置错误,导致异常不满足回滚条件

直接看代码:

    @Transactional
    public void addUser(UserParam param) {
      User user = PtcBeanUtils.copy(param, User.class);
       
      .......
        
      // 添加用户角色
      this.addUserRole(user.getId(), param.getRoleIds());
      log.info("执行结束了");
    }
​
    public void addUserRole(Long userId, List roleIds) throws Exception {
        if (CollectionUtils.isEmpty(roleIds)) {
            return;
        }
        List userRoles = new ArrayList();
        roleIds.forEach(roleId -> {
            UserRole userRole = new UserRole();
            userRole.setUserId(userId);
            userRole.setRoleId(roleId);
            userRoles.add(userRole);
        });
        userRoleDAO.insertBatch(userRoles);
        throw new Exception("发生异常咯");
    }

在#addUser()方法中,尽管使用了@Transactional注解,但却没有显式设置rollbackFor属性。此外,#addUserRole()方法所抛出的异常类型为exception,而非RuntimeException。这种设置导致事务失效,因为在默认情况下,Spring仅会在出现RuntimeException(非受检异常)或Error时才会触发事务回滚机制。

在3.2小节中的completeTransactionAfterThrowing(txInfo, ex)方法中,进行回滚操作的判断会检查异常类型是否符合特定规定。查看DefaultTransactionAttribute类的相关代码块,可以发现如下内容,这些细节为我们提供了相关证据。同时,通过注释也能够理解Spring采取这种处理方式的原因。简单来说,受检异常通常是业务异常,或者可以看作是类似于另一种方法返回值的异常。在这种情况下,虽然出现异常,但业务可能仍然可以继续执行,所以并不会主动触发事务回滚。而Error或RuntimeException则代表了非预期的异常情况,因此应该触发事务回滚以保证数据的一致性。

  public boolean rollbackOn(Throwable ex) {
    return (ex instanceof RuntimeException || ex instanceof Error);
  }

修正方法:设置rollbackFor@Transactional(rollbackFor = Exception.class)

3.4 @Transactional 应用在非 public 修饰的方法上

    @Transactional(rollbackFor = Exception.class)
    private void addUserRole(Long userId, List roleIds) {
        if (CollectionUtils.isEmpty(roleIds)) {
            return;
        }
        ListuserRoles = new ArrayList();
        roleIds.forEach(roleId -> {
            UserRole userRole = new UserRole();
            userRole.setUserId(userId);
            userRole.setRoleId(roleId);
            userRoles.add(userRole);
        });
        userRoleDAO.insertBatch(userRoles);
        throw new RuntimeException("发生异常咯");
    }

idea也会提示错误:

Spring利用CGLIB动态代理来增强生成代理对象,CGLIB通过继承的方式实现代理类,但是私有方法在子类中是不可见的,因此也无法进行事务增强

修正方式:直接是改成public

3.5 @Transactional 注解传播属性 propagation 设置错误

如上面我们新增的用户的同时要添加用户角色,但是假如我们希望即使添加角色错误了,还可以正常新增用户。

 public void addUser(UserParam param) {
      String username = param.getUsername();
      checkUsernameUnique(username);
      User user = PtcBeanUtils.copy(param, User.class);
      // 添加用户
      userDAO.insert(user);
​
      // 添加用户角色
      userRoleService.addUserRole(user.getId(), param.getRoleIds());
    
 }

#userRoleService.addUserRole()

  @Transactional(rollbackFor = Exception.class)
  private void addUserRole(Long userId, List roleIds) {
      if (CollectionUtils.isEmpty(roleIds)) {
          return;
      }
      ListuserRoles = new ArrayList();
      roleIds.forEach(roleId -> {
          UserRole userRole = new UserRole();
          userRole.setUserId(userId);
          userRole.setRoleId(roleId);
          userRoles.add(userRole);
      });
      userRoleDAO.insertBatch(userRoles);
      throw new RuntimeException("发生异常咯");
  }

你会发现只会同时插入失败,无法实现上面所说的。这时候你可能会想到,既然addUserRole()抛出了异常不能插入用户角色,但是addUser()不想受影响,正常添加用户,那么何不在addUser()里面对userRoleService.addUserRole()进行异常捕获,不就可以解决问题了吗?真是如此吗,就让我们来验证一下:

    @Transactional(rollbackFor = Exception.class)
    public void addUser(UserParam param) {
        User user = PtcBeanUtils.copy(param, User.class);
        // 添加用户
        userDAO.insert(user);
        // 添加用户角色
        try {
            userRoleService.addUserRole(user.getId(), param.getRoleIds());
        } catch (Exception e) {
            log.error(e.getMessage());
        }
    }

执行会发现,用户同样没有添加成功,看日志报错:

[1689568520410750976] [ERROR] [2023-08-10 17:25:02.023] [http-nio-18888-exec-1@56682]  com.plasticene.fast.service.impl.UserServiceImpl addUser : 发生异常咯
[1689568520410750976] [ERROR] [2023-08-10 17:25:02.097] [http-nio-18888-exec-1@56682]  com.plasticene.boot.web.core.global.GlobalExceptionHandler exceptionHandler : 【系统异常】
org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
  at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:870)

可以看到发生异常咯是我们在addUser()中捕获到输出的,但是紧接着下一行发现有报出一个异常UnexpectedRollbackException

原因是,主方法添加用户的逻辑和子方法添加用户角色的逻辑是同一个事务,子逻辑标记了事务需要回滚,主逻辑自然也不能提交了。

修正方式:其实要想新增用户角色失败不影响添加用户,只需要让新增用户角色单独开启一个新事务即可。

   @Transactional(rollbackFor = Exception.class, propagation = Propagation.REQUIRES_NEW)
    public void addUserRole(Long userId, List roleIds) {
        ListuserRoles = new ArrayList();
        roleIds.forEach(roleId -> {
            UserRole userRole = new UserRole();
            userRole.setUserId(userId);
            userRole.setRoleId(roleId);
            userRoles.add(userRole);
        });
        userRoleDAO.insertBatch(userRoles);
        throw new RuntimeException("发生异常啦!");
    }

3.6 @Transactional长事务导致生产事故

很多开发者对于Spring的声明式事务使用(即@Transactional注解)感觉非常简单,因此容易忽略细节。当Spring遇到这个注解时,它会自动从数据库连接池中获取连接,并启动事务,然后将连接绑定到ThreadLocal上。整个被@Transactional注解包裹的方法会使用同一个连接。然而,如果方法中存在耗时的操作,比如第三方接口调用、复杂的业务逻辑或大批量数据处理等,就可能导致连接被占用的时间过长,进而导致数据库连接一直处于占用状态。当这种操作过于频繁时,就会导致数据库连接池资源耗尽,形成典型的长事务问题。

长事务问题带来的常见危害有:

  1. 数据库连接池资源耗尽,导致应用无法获取连接资源。
  2. 容易引发数据库死锁问题。
  3. 数据库回滚时间变长,影响性能。
  4. 在主从架构中可能导致主从延时增大。

一旦长事务问题出现,服务系统可能会出现多种故障表现:数据库监控平台频繁报告连接不足,大量死锁问题;系统日志显示调用流程引擎接口超时现象频发;同时也可能不断出现CannotGetJdbcConnectionException错误,因为数据库连接池的连接被耗尽。

解决这个问题并不难,关键在于对方法进行拆分,将不需要事务管理的逻辑与需要事务操作的逻辑分开,从而有效控制事务的执行时长,避免长事务问题。虽然这种方法可能会导致一个方法的逻辑拆分成多个子方法,有时可能会引发事务不生效的问题,但结合你之前的总结,我相信你已经能够正确应对这些情况了。

4.总结

Spring的声明式事务利用@Transactional注解确实使开发变得十分便捷。然而,稍有不慎使用不当便可能引发事务失效、数据不一致甚至系统数据库性能问题。正因如此,上述充满干货的总结均源自实际工作中的实践,对于规避这些陷阱起到了积极的作用。这些经验能够有效地助你避免在开发过程中掉入坑中。


版权声明:本站文章,如无说明,均为本站原创,转载请注明文章来源。如有侵权,请联系博主删除。
本文链接:https://www.panziye.com/java/8167.html
喜欢 (0)
请潘老师喝杯Coffee吧!】
分享 (0)
用户头像
发表我的评论
取消评论
表情 贴图 签到 代码

Hi,您需要填写昵称和邮箱!

  • 昵称【必填】
  • 邮箱【必填】
  • 网址【可选】