Spring事务失效、Spring事务和锁冲突

芝士汉堡 ིྀིྀ

已于 2024-06-22 15:08:35 修改

阅读量1k

点赞数 2

文章标签： java spring

于 2023-03-08 10:40:17 首次发布

本文链接：https://blog.csdn.net/weixin_51596697/article/details/129398033

版权

Spring事务的实现

Spring提供了很好事务管理机制，主要分为编程式事务和声明式事务两种。

1.编程式事务

	 @Autowired
    private TransactionTemplate transactionTemplate;

    public void performTransaction() {
        transactionTemplate.execute(new TransactionCallbackWithoutResult() {
            @Override
            protected void doInTransactionWithoutResult(TransactionStatus status) {
                try {
                    // 执行事务内的逻辑
                    myRepository.saveData();
                    myRepository.updateData();

                    // 如果需要手动触发回滚，可以通过以下方式
                    // status.setRollbackOnly();
                } catch (Exception e) {
                    // 发生异常时，Spring 会自动触发回滚
                    // 如果需要手动回滚，也可以在这里设置 status.setRollbackOnly();
                    throw new RuntimeException("Transaction failed", e);
                }
            }
        });
    }

2.声明式事务

基于AOP面向切面的，它将具体业务与事务处理部分解耦，代码侵入性很低，所以在实际开发中声明式事务用的比较多。声明式事务也有两种实现方式，一是基于TX和AOP的xml配置文件方式，二种就是基于@Transactional注解了。

2.1 @Transactional 作用

Transactional 可以作用在接口、类、类方法。

在类上时，表示所有该类的public方法都配置相同的事务属性信息。

作用于方法：当类配置了@Transactional，方法也配置了@Transactional，方法的事务会覆盖类的事务配置信息。

作用于接口：不推荐这种使用方法，因为一旦标注在Interface上并且配置了Spring AOP 使用CGLib动态代理，将会导致@Transactional注解失效

2.2 @Transactional 属性

propagation 代表事务的传播行为，默认值为 Propagation.REQUIRED，其他的属性信息如下：

Propagation.REQUIRED：如果当前存在事务，则加入该事务，如果当前不存在事务，则创建一个新的事务。( 也就是说如果A方法和B方法都添加了注解，在默认传播模式下，A方法内部调用B方法，会把两个方法的事务合并为一个事务 ）

Propagation.SUPPORTS：如果当前存在事务，则加入该事务；如果当前不存在事务，则以非事务的方式继续运行。

Propagation.MANDATORY：如果当前存在事务，则加入该事务；如果当前不存在事务，则抛出异常。

Propagation.REQUIRES_NEW：重新创建一个新的事务，如果当前存在事务，暂停当前的事务。( 当类A中的 a 方法用默认Propagation.REQUIRED模式，类B中的 b方法加上采用 Propagation.REQUIRES_NEW模式，然后在 a 方法中调用 b方法操作数据库，然而 a方法抛出异常后，b方法并没有进行回滚，因为Propagation.REQUIRES_NEW会暂停 a方法的事务 )

Propagation.NOT_SUPPORTED：以非事务的方式运行，如果当前存在事务，暂停当前的事务。

Propagation.NEVER：以非事务的方式运行，如果当前存在事务，则抛出异常。

Propagation.NESTED ：和 Propagation.REQUIRED 效果一样。

isolation ：事务的隔离级别，默认值为 Isolation.DEFAULT。

Isolation.DEFAULT：使用底层数据库默认的隔离级别。也就是可重复读

Isolation.READ_UNCOMMITTED 读未提交，在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。不能避免脏读、不可重复读、幻读。

Isolation.READ_COMMITTED  读已提交，它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。可以避免脏读，但不可重复读、幻读问题仍然存在。

Isolation.REPEATABLE_READ 可重复读，事务A在读到一条数据之后，此时事务B对该数据进行了修改并提交，那么事务A再读该数据，读到的还是原来的内容。可以避免脏读、不可重复读，但幻读问题仍然存在。这是MySQL的默认隔离级别。

Isolation.SERIALIZABLE 可串行化，确保事务可以从一个表中读取相同的行。在这个事务持续期间，禁止其他事务对该表执行插入、更新和删除操作。所有的并发问题都可以避免，但性能十分低下。能避免脏读、不可重复读和幻读。

timeout 属性

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

readOnly 属性

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

rollbackFor 属性

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

noRollbackFor属性

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

Spring事务失效概述

Spring对事务的管理和处理，是基于AOP和编程范式的。因此Spring事务失效的场景较为丰富，包括但不限于以下常见情况：

异常被吞掉：当事务管理中出现异常但没有被正确捕捉并处理时，事务就会失效。例如，在try-catch块中吞掉了异常，或者在自己的业务代码逻辑内部错误处理中有问题。
不受检查异常：Spring默认只对运行时异常(Runtime exceptions)进行事务回滚，而不受检查的异常（Unchecked exceptions）就是运行时异常的一种。例如NullPointerException、IndexOutOfBoundsException等都是运行时异常，Spring会对这些异常进行事务回滚。
不合适的事务超时设置：如果在执行一条事务时，该事务超时时间比事务实际执行的时间还短，事务会被标记为超时，从而导致事务失效。事务超时的设置应考虑到事务的性质以及执行时间，并做出相应的操作。
锁竞争：在并发的情况下，若操作的数据已被加锁，则可能会在事务中启动而无法正常执行。例如，死锁、死循环、同步问题等。
调用非public方法：在使用Spring的编程式事务时，直接在类的内部调用方法并未经过代理，可能导致事务失效。这时，在该方法内部开启的事务不会被正确地传递到代理对象中。
数据库链接被关闭：如果数据源在事务执行期间被关闭，则事务管理器无法继续使用数据库链接，从而导致事务无法进行。

需要注意的是，以上列举的是常见情况，并不是具有穷尽性。在实际应用中，还需要根据具体情况综合考虑，并进行避免和解决。

Spring事务失效具体场景及决解办法

1.抛出检查异常导致事务不能正确回滚

@Service
public class Service1 {

    @Autowired
    private AccountMapper accountMapper;

    @Transactional
    public void transfer(int from, int to, int amount) throws FileNotFoundException {
        int fromBalance = accountMapper.findBalanceBy(from);
        if (fromBalance - amount >= 0) {
            accountMapper.update(from, -1 * amount);
            new FileInputStream("aaa");
            accountMapper.update(to, amount);
        }
    }
}

原因：Spring 默认只会回滚非检查异常
解法：配置 rollbackFor 属性
- @Transactional(rollbackFor = Exception.class)

2. 业务方法内自己 try-catch 异常导致事务不能正确回滚

@Service
public class Service2 {

    @Autowired
    private AccountMapper accountMapper;

    @Transactional(rollbackFor = Exception.class)
    public void transfer(int from, int to, int amount)  {
        try {
            int fromBalance = accountMapper.findBalanceBy(from);
            if (fromBalance - amount >= 0) {
                accountMapper.update(from, -1 * amount);
                new FileInputStream("aaa");
                accountMapper.update(to, amount);
            }
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        }
    }
}

原因：事务通知只有捉到了目标抛出的异常，才能进行后续的回滚处理，如果目标自己处理掉异常，事务通知无法知悉
解法1：异常原样抛出
- 在 catch 块添加 throw new RuntimeException(e);
解法2：手动设置 TransactionStatus.setRollbackOnly()
- 在 catch 块添加 TransactionInterceptor.currentTransactionStatus().setRollbackOnly();

3. aop 切面顺序导致导致事务不能正确回滚

@Service
public class Service3 {

    @Autowired
    private AccountMapper accountMapper;

    @Transactional(rollbackFor = Exception.class)
    public void transfer(int from, int to, int amount) throws FileNotFoundException {
        int fromBalance = accountMapper.findBalanceBy(from);
        if (fromBalance - amount >= 0) {
            accountMapper.update(from, -1 * amount);
            new FileInputStream("aaa");
            accountMapper.update(to, amount);
        }
    }
}

@Aspect
public class MyAspect {
    @Around("execution(* transfer(..))")
    public Object around(ProceedingJoinPoint pjp) throws Throwable {
        LoggerUtils.get().debug("log:{}", pjp.getTarget());
        try {
            return pjp.proceed();
        } catch (Throwable e) {
            e.printStackTrace();
            return null;
        }
    }
}

原因：事务切面优先级最低，但如果自定义的切面优先级和他一样，则还是自定义切面在内层，这时若自定义切面没有正确抛出异常…
解法1、2：同情况2 中的解法:1、2
解法3：调整切面顺序，在 MyAspect 上添加 @Order(Ordered.LOWEST_PRECEDENCE - 1) （不推荐）

4. 非 public 方法导致的事务失效

@Service
public class Service4 {

    @Autowired
    private AccountMapper accountMapper;

    @Transactional
    void transfer(int from, int to, int amount) throws FileNotFoundException {
        int fromBalance = accountMapper.findBalanceBy(from);
        if (fromBalance - amount >= 0) {
            accountMapper.update(from, -1 * amount);
            accountMapper.update(to, amount);
        }
    }
}

原因：之所以会失效是因为在Spring AOP 代理时，TransactionInterceptor （事务拦截器）在目标方法执行前后进行拦截，DynamicAdvisedInterceptor（CglibAopProxy 的内部类）的 intercept 方法或 JdkDynamicAopProxy 的 invoke 方法会间接调用 AbstractFallbackTransactionAttributeSource的 computeTransactionAttribute 方法，获取Transactional 注解的事务配置信息。

protected TransactionAttribute computeTransactionAttribute(Method method,
    Class<?> targetClass) {
        // Don't allow no-public methods as required.
        if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {
        return null;
}

此方法会检查目标方法的修饰符是否为 public，不是 public则不会获取@Transactional 的属性配置信息。总的来说Spring 为方法创建代理、添加事务通知、前提条件都是该方法是 public 的。

解法1：改为 public 方法
解法2：添加 bean 配置如下（不推荐）

@Bean
public TransactionAttributeSource transactionAttributeSource() {
    return new AnnotationTransactionAttributeSource(false);
}

5. 父子容器导致的事务失效

@Service
public class Service5 {

    @Autowired
    private AccountMapper accountMapper;

    @Transactional(rollbackFor = Exception.class)
    public void transfer(int from, int to, int amount) throws FileNotFoundException {
        int fromBalance = accountMapper.findBalanceBy(from);
        if (fromBalance - amount >= 0) {
            accountMapper.update(from, -1 * amount);
            accountMapper.update(to, amount);
        }
    }
}

控制器类

@Controller
public class AccountController {

    @Autowired
    public Service5 service;

    public void transfer(int from, int to, int amount) throws FileNotFoundException {
        service.transfer(from, to, amount);
    }
}

App配置类

@Configuration
@ComponentScan("day04.tx.app.service")
@EnableTransactionManagement
// ...
public class AppConfig {
    // ... 有事务相关配置
}

Web配置类

@Configuration
@ComponentScan("day04.tx.app")
// ...
public class WebConfig {
    // ... 无事务配置
}

现在配置了父子容器，WebConfig 对应子容器，AppConfig 对应父容器，发现事务依然失效

原因：子容器扫描范围过大，把未加事务配置的 service 扫描进来
解法1：各扫描各的，不要图简便
解法2：不要用父子容器，所有 bean 放在同一容器

6. 调用本类方法导致传播行为失效

@Service
public class Service6 {

    @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
    public void foo() throws FileNotFoundException {
        LoggerUtils.get().debug("foo");
        bar();
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = Exception.class)
    public void bar() throws FileNotFoundException {
        LoggerUtils.get().debug("bar");
    }
}

原因：同一个类中方法调用，导致@Transactional失效，开发中避免不了会对同一个类里面的方法调用，比如有一个类Test，它的一个方法A，A再调用本类的方法B（不论方法B是用public还是private修饰），但方法A没有声明注解事务，而B方法有。则外部调用方法A之后，方法B的事务是不会起作用的。这也是经常犯错误的一个地方。

那为啥会出现这种情况？其实这还是由于使用Spring AOP代理造成的，因为只有当事务方法被当前类以外的代码调用时，才会由Spring生成的代理对象来管理。总的来说本类方法调用不经过代理，因此无法增强。

解法1：依赖注入自己（代理）来调用
解法2：通过 AopContext 拿到代理对象，来调用
解法3：通过 CTW，LTW 实现功能增强

解法1：

@Service
public class Service6 {

	@Autowired
	private Service6 proxy; // 本质上是一种循环依赖

    @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
    public void foo() throws FileNotFoundException {
        LoggerUtils.get().debug("foo");
		System.out.println(proxy.getClass());
		proxy.bar();
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = Exception.class)
    public void bar() throws FileNotFoundException {
        LoggerUtils.get().debug("bar");
    }
}

解法2，还需要在 AppConfig 上添加 @EnableAspectJAutoProxy(exposeProxy = true)

@Service
public class Service6 {
    
    @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
    public void foo() throws FileNotFoundException {
        LoggerUtils.get().debug("foo");
        ((Service6) AopContext.currentProxy()).bar();
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = Exception.class)
    public void bar() throws FileNotFoundException {
        LoggerUtils.get().debug("bar");
    }
}

7. @Transactional 没有保证原子行为

@Service
public class Service7 {

    private static final Logger logger = LoggerFactory.getLogger(Service7.class);

    @Autowired
    private AccountMapper accountMapper;

    @Transactional(rollbackFor = Exception.class)
    public void transfer(int from, int to, int amount) {
        int fromBalance = accountMapper.findBalanceBy(from);
        logger.debug("更新前查询余额为: {}", fromBalance);
        if (fromBalance - amount >= 0) {
            accountMapper.update(from, -1 * amount);
            accountMapper.update(to, amount);
        }
    }

    public int findBalance(int accountNo) {
        return accountMapper.findBalanceBy(accountNo);
    }
}

上面的代码实际上是有 bug 的，假设 from 余额为 1000，两个线程都来转账 1000，可能会出现扣减为负数的情况

原因：事务的原子性仅涵盖 insert、update、delete、select … for update 语句，select 方法并不阻塞
如上图所示，红色线程和蓝色线程的查询都发生在扣减之前，都以为自己有足够的余额做扣减

8. @Transactional 方法导致的 synchronized 失效

针对上面的问题，能否在方法上加 synchronized 锁来解决呢？

代码执行流程：开启事务–》上锁–》执行业务–》解锁–》提交事务

@Service
public class Service7 {

    private static final Logger logger = LoggerFactory.getLogger(Service7.class);

    @Autowired
    private AccountMapper accountMapper;

    @Transactional(rollbackFor = Exception.class)
    public synchronized void transfer(int from, int to, int amount) {
        int fromBalance = accountMapper.findBalanceBy(from);
        logger.debug("更新前查询余额为: {}", fromBalance);
        if (fromBalance - amount >= 0) {
            accountMapper.update(from, -1 * amount);
            accountMapper.update(to, amount);
        }
    }

    public int findBalance(int accountNo) {
        return accountMapper.findBalanceBy(accountNo);
    }
}

答案是不行，原因如下：

Spring事务会在执行方法之前开启事务，然后上锁执行代码逻辑，解锁，提交事务。会出现如下情况：在第一个线程解锁时候，还没提交事务。第二个线程已经开启事务，上锁，这时候读取的数据不是最新的，造成业务出错。并且mysql默认重复读，所以出现上面的问题。

synchronized 保证的仅是目标方法的原子性，环绕目标方法的还有 commit 等操作，它们并未处于 sync 块内
可以参考下图发现，蓝色线程的查询只要在红色线程提交之前执行，那么依然会查询到有 1000 足够余额来转账

解决办法
既然事务下不能使用锁，那我们把锁和事务进行分开。使得在锁环境下包含事务，最终依然是线程安全的。

办法1：将synchronized和Redis锁提取到controller层，不包含任何事务。
办法2：在service下新建无事务的方法，将有事务代码的抽取单独使用。直接在无事务方法调用有事务的方法，这样依旧能保证线程安全。
方法3：将分布式锁替换成数据库的锁比如select for update或者版本号version

SELECT…FOR UPDATE是一种行级锁定机制，在数据库中用来保证数据的一致性和并发时的正确性。当一个事务需要读取一条数据并进行修改，如果不加锁，可能会出现脏写或者并发读取的问题，严重时可能导致数据的不一致性。而使用SELECT…FOR UPDATE可以在读取数据的同时将该数据加锁，保证其他事务无法并发修改该数据。

SELECT…FOR UPDATE的使用方式为：

SELECT * FROM table_name WHERE search_condition  FOR UPDATE;

其中，search_condition是搜索条件，可以是一系列AND/OR组合的表达式；FOR UPDATE表示加锁，即锁定符合搜索条件的所有行。

SELECT…FOR UPDATE语句在事务中才会对搜索到的数据做行级锁定，因此在事务结束之前其他事务无法修改该行数据，如果长时间加锁可能会导致性能问题或死锁的情况，应根据具体情况谨慎使用。若不需要进行修改操作，建议使用SELECT语句或者其他更适合的数据库访问操作，以提高系统并发量和性能。