@Transactional中使用线程锁导致了锁失效与解决方案

2024-08-23 12:04

本文主要是介绍@Transactional中使用线程锁导致了锁失效与解决方案,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

@Transactional中使用线程锁导致了锁失效

今天给大家分享一个线上系统里发现的生产实践案例,就是平时大家应该都会用@Transactional注解去实现事务是不是?因为这个注解底层说白了很简单,就是会去代理你这个方法的执行,一旦代理了你的方法执行,其实就可以在方法执行前开一个事务,方法执行完以后如果成功就提交事务,有异常就回滚事务。

这样就可以让你这个方法里所有的数据库操作汇集到一个事务里去了,这个相信大家其实都是懂的,平时 开发也都是这么做的。

那大家有没有想过,要是我们在这个事务注解里用了多线程并发加锁的代码,可能会导致这个锁失效,也就是没法实现多线程在加锁代码里串行加锁执行?这个简直是一个巨坑,妥妥的线上生产事故案例,下面我们就开始分下这个案例。

一、@Transactional与线程锁的基本使用

首先,我们简要回顾一下@Transactional和线程锁的基本用法。

1. @Transactional注解

@Transactional注解可以应用于接口定义、接口中的方法、类定义或类中的public方法上。其主要作用是声明一个方法需要在事务环境中执行。Spring框架会在运行时通过AOP(面向切面编程)代理机制,自动管理事务的开启、提交和回滚。

@Service
public class SomeService {@Transactionalpublic void someTransactionalMethod() {// 业务逻辑}
}

2. 线程锁(如ReentrantLock)

线程锁用于控制多个线程对共享资源的并发访问,防止数据不一致的问题。ReentrantLock是Java并发包java.util.concurrent.locks中的一个类,它提供了比synchronized关键字更灵活的锁定操作。

public class SomeClass {private final Lock lock = new ReentrantLock();public void someMethod() {lock.lock();try {// 业务逻辑} finally {lock.unlock();}}
}

二、@Transactional中使用线程锁导致的问题

@Transactional注解的方法内部使用线程锁时,可能会遇到锁失效的问题。这是因为@Transactional通过AOP在目标方法执行前后进行事务的开启和提交,而线程锁则直接作用于方法内部的代码块。这种机制上的差异导致了事务和锁的管理在时间上不一致,进而引发锁失效。

示例场景

假设我们有一个服务类,其中有一个方法需要在事务环境中更新数据库记录,并在这个过程中使用线程锁控制并发访问。

@Service
public class UpdateService {private final Lock lock = new ReentrantLock();@Transactionalpublic void updateData() {lock.lock();try {// 模拟数据库更新操作System.out.println("Updating data...");// 假设这里有一些耗时的数据库操作Thread.sleep(1000);} catch (InterruptedException e) {Thread.currentThread().interrupt();} finally {lock.unlock();}}
}

在这个例子中,虽然我们在方法内部使用了ReentrantLock来加锁,但锁的释放是在事务提交之前完成的。如果在锁释放后、事务提交前,有其他线程进入并尝试更新相同的数据,就可能读取到未提交的数据,从而导致数据不一致。

因为一旦把事务和锁放一起用,就会显得有点诡异,你上面的代码想的是说用事务注解控制数据库事务,异常就回滚,成功就提交,对吧?然后你想加锁以后就是每个线程串行执行,一个线程加锁,更新数据库,提交事务,释放锁,下一个线程过来加锁,读取更新数据库,注意,这里应该是接着上一个现成的更新结果来做的,完了再提交事务,释放锁,对吧?

问题是,如果忽略了事务注解的工作机制,忘了那个事务控制其实是在锁代码外面的,因为spring会用AOP代理机制接管方法执行,事务管控是在方法执行外面的,所以很可能你开启一共事务,然后加锁,执行数据库更新,接着就直接释放锁了,然后此时事务可能还没提交!!!!

接着别的线程就可以进入一个方法了,此时他会开启一个自己的事务,在mysql层面多个事务并发的时候是有自己的隔离机制的,跟你的代码里的加锁是没直接关系的,此时新的线程是可以进入代码块拿到锁的,毕竟你之前一个线程都释放代码里的锁了!

然后新的线程执行数据库的读取和更新操作,其实是基于上一个线程的事务没提交的那个脏数据在执行,所以此时就会出现数据不一致的情况,看起来就跟多个线程乱序更新数据库一样,跟你想的就不一样了,对吧?

所以这就是所谓的事务注解里线程加锁可能导致锁没生效,多个线程还是乱序在执行。

三、问题分析

问题的根源在于@Transactional和线程锁的管理机制不同步。@Transactional通过AOP代理在方法执行前后进行事务操作,而线程锁则是直接在方法内部控制并发。当方法执行完毕后,即使事务还未提交,锁已经被释放,这就为其他线程提供了进入并操作共享资源的机会。

四、解决方案

为了解决@Transactional中使用线程锁导致的锁失效问题,我们可以采用以下几种方案:

1. 将事务管理和锁操作分离

将需要加锁的业务逻辑封装到一个单独的方法中,并在调用该方法前手动管理事务。这种方式可以避免@Transactional和线程锁在时间上的不一致。也就是通过手动管控事务提交和回滚,跟代码里的加锁同步一致,避免这个问题。

按照我们的想法,说白了就是应该是在加锁代码里面让事务先提交,然后再释放锁,这样就可以保证多个线程对数据库的更新是串行的。

@Service
public class UpdateService {private final Lock lock = new ReentrantLock();@Autowiredprivate PlatformTransactionManager transactionManager;public void updateData() {lock.lock();try {TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());try {// 模拟数据库更新操作System.out.println("Updating data...");// 假设这里有一些耗时的数据库操作Thread.sleep(1000);transactionManager.commit(status);} catch (Exception e) {transactionManager.rollback(status);throw e;}} catch (InterruptedException e) {Thread.currentThread().interrupt();} finally {lock.unlock();}}
}

注意:这种方式虽然解决了锁失效的问题,但手动管理事务会使代码变得复杂,且容易出错。

2. 使用@Transactional单独一个方法

将需要事务支持的方法单独提出来,并确保该方法不包含任何锁操作。在调用该方法前,通过其他方式(如使用代理类或直接在调用者处)管理锁。这个本质其实也是在锁范围内让事务先执行和提交,只不过通过方法的提取避免了手动加提交事务,其实是更加的优雅的!

@Service
public class UpdateServiceImpl implements UpdateService {@Autowired@Lazyprivate UpdateServiceImpl self;private final Lock lock = new ReentrantLock();@Transactionalpublic void updateDataTransactional() {// 模拟数据库更新操作System.out.println("Updating data in transaction...");// 假设这里有一些耗时的数据库操作Thread.sleep(1000);}public void updateData() {lock.lock();try {self.updateDataTransactional();} catch (InterruptedException e) {Thread.currentThread().interrupt();} finally {lock.unlock();}}
}

这种方式将事务管理和锁操作分离到不同的方法中,既保证了事务的正确性,又避免了锁失效的问题。

3. 使用数据库锁代替线程锁

在某些情况下,我们可以考虑使用数据库本身的锁机制来替代线程锁。数据库锁可以更加精确地控制对共享资源的访问,且与事务管理紧密结合,不易出现锁失效的问题。

五、总结

@Transactional注解的方法内部使用线程锁时,由于事务管理和锁操作在时间上的不一致,可能会导致锁失效的问题。为了解决这个问题,我们可以将事务管理和锁操作分离,使用编程式事务管理,或者将需要事务支持的方法单独提出来,并通过其他方式管理锁。同时,我们也可以考虑使用数据库锁来替代线程锁,以更好地保证数据的一致性和完整性。

希望这篇文章能帮助你更好地理解@Transactional中使用线程锁导致的问题,并提供实用的解决方案。在实际开发中,根据具体场景选择合适的方法,可以有效避免类似问题的发生。

关于数据库锁代替线程锁上个demo:

下面是一个示例,演示如何使用数据库行级锁来代替线程锁,确保多个线程在操作相同记录时实现串行化操作。

场景描述

假设有一个银行账户管理系统,多个线程可能会同时更新一个账户的余额。为了避免并发问题,我们需要确保每个线程在更新余额时,其他线程不能修改同一账户的数据。

使用线程锁的实现方式(问题示例)

@Service
public class AccountService {private final Lock lock = new ReentrantLock();@Transactionalpublic void updateBalance(Long accountId, BigDecimal amount) {lock.lock();try {Account account = accountRepository.findById(accountId).orElseThrow();account.setBalance(account.getBalance().add(amount));accountRepository.save(account);} finally {lock.unlock();}}
}

这种方式的问题在于,事务提交可能会在锁释放后发生,从而引发并发问题。

使用数据库锁的实现方式

可以通过SELECT ... FOR UPDATE语句来获取数据库的行级锁,以确保在整个事务过程中,这行数据不会被其他事务修改。

@Service
public class AccountService {@Transactionalpublic void updateBalance(Long accountId, BigDecimal amount) { // 使用 FOR UPDATE 锁定账户记录 Account account = accountRepository.findByIdForUpdate(accountId).orElseThrow();account.setBalance(account.getBalance().add(amount));accountRepository.save(account);}
}

AccountRepository接口

public interface AccountRepository extends JpaRepository<Account, Long> {// 使用 @Query 注解执行 FOR UPDATE 语句,锁定行@Query("SELECT a FROM Account a WHERE a.id = :accountId FOR UPDATE")Optional<Account> findByIdForUpdate(@Param("accountId") Long accountId);
}

解释

  1. 行级锁:通过FOR UPDATE,数据库会在事务中锁定该行数据,直到事务提交或回滚。这确保了其他事务在此期间无法读取或修改这行数据。
  2. 事务管理:因为锁和事务管理是在数据库层面进行的,所以可以确保在锁定的数据上操作的事务都能够保持一致性。

优点

  • 数据库锁与事务管理集成:不需要额外的线程锁逻辑,减少了代码复杂性。
  • 精确控制并发:数据库层面的锁定更加精确,能够避免传统线程锁可能带来的锁失效问题。

通过这种方式,可以确保多个线程在更新相同数据时,能够串行地执行,避免出现数据不一致的问题。

这篇关于@Transactional中使用线程锁导致了锁失效与解决方案的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!


原文地址:
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.chinasem.cn/article/1099329

相关文章

深入理解Go语言中二维切片的使用

《深入理解Go语言中二维切片的使用》本文深入讲解了Go语言中二维切片的概念与应用,用于表示矩阵、表格等二维数据结构,文中通过示例代码介绍的非常详细,需要的朋友们下面随着小编来一起学习学习吧... 目录引言二维切片的基本概念定义创建二维切片二维切片的操作访问元素修改元素遍历二维切片二维切片的动态调整追加行动态

prometheus如何使用pushgateway监控网路丢包

《prometheus如何使用pushgateway监控网路丢包》:本文主要介绍prometheus如何使用pushgateway监控网路丢包问题,具有很好的参考价值,希望对大家有所帮助,如有错误... 目录监控网路丢包脚本数据图表总结监控网路丢包脚本[root@gtcq-gt-monitor-prome

Python通用唯一标识符模块uuid使用案例详解

《Python通用唯一标识符模块uuid使用案例详解》Pythonuuid模块用于生成128位全局唯一标识符,支持UUID1-5版本,适用于分布式系统、数据库主键等场景,需注意隐私、碰撞概率及存储优... 目录简介核心功能1. UUID版本2. UUID属性3. 命名空间使用场景1. 生成唯一标识符2. 数

SpringBoot中如何使用Assert进行断言校验

《SpringBoot中如何使用Assert进行断言校验》Java提供了内置的assert机制,而Spring框架也提供了更强大的Assert工具类来帮助开发者进行参数校验和状态检查,下... 目录前言一、Java 原生assert简介1.1 使用方式1.2 示例代码1.3 优缺点分析二、Spring Fr

Android kotlin中 Channel 和 Flow 的区别和选择使用场景分析

《Androidkotlin中Channel和Flow的区别和选择使用场景分析》Kotlin协程中,Flow是冷数据流,按需触发,适合响应式数据处理;Channel是热数据流,持续发送,支持... 目录一、基本概念界定FlowChannel二、核心特性对比数据生产触发条件生产与消费的关系背压处理机制生命周期

java使用protobuf-maven-plugin的插件编译proto文件详解

《java使用protobuf-maven-plugin的插件编译proto文件详解》:本文主要介绍java使用protobuf-maven-plugin的插件编译proto文件,具有很好的参考价... 目录protobuf文件作为数据传输和存储的协议主要介绍在Java使用maven编译proto文件的插件

Javaee多线程之进程和线程之间的区别和联系(最新整理)

《Javaee多线程之进程和线程之间的区别和联系(最新整理)》进程是资源分配单位,线程是调度执行单位,共享资源更高效,创建线程五种方式:继承Thread、Runnable接口、匿名类、lambda,r... 目录进程和线程进程线程进程和线程的区别创建线程的五种写法继承Thread,重写run实现Runnab

SpringBoot线程池配置使用示例详解

《SpringBoot线程池配置使用示例详解》SpringBoot集成@Async注解,支持线程池参数配置(核心数、队列容量、拒绝策略等)及生命周期管理,结合监控与任务装饰器,提升异步处理效率与系统... 目录一、核心特性二、添加依赖三、参数详解四、配置线程池五、应用实践代码说明拒绝策略(Rejected

C++ Log4cpp跨平台日志库的使用小结

《C++Log4cpp跨平台日志库的使用小结》Log4cpp是c++类库,本文详细介绍了C++日志库log4cpp的使用方法,及设置日志输出格式和优先级,具有一定的参考价值,感兴趣的可以了解一下... 目录一、介绍1. log4cpp的日志方式2.设置日志输出的格式3. 设置日志的输出优先级二、Window

Ubuntu如何分配​​未使用的空间

《Ubuntu如何分配​​未使用的空间》Ubuntu磁盘空间不足,实际未分配空间8.2G因LVM卷组名称格式差异(双破折号误写)导致无法扩展,确认正确卷组名后,使用lvextend和resize2fs... 目录1:原因2:操作3:报错5:解决问题:确认卷组名称​6:再次操作7:验证扩展是否成功8:问题已解