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

本文主要是介绍@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);
}