解决@Transactional遇上@synchronized的生产问题_开发_开发者

@Transactional遇上@synchronized的生产问题

近日遇到一个问题，就是一个订单被两个用户抢了问题，排查后发现是由于 @Transactional和@synchronized注解的使用问题

解决@Transactional遇上@synchronized的生产问题

一、问题点：数据重复读

@Transactional注解用于开启事务，当在高并发情况下我们可能为了保证数据的安全使用悲观锁，可以在方php法上使用@synchronized使用悲观锁。一个线程执行完方法并释放锁后，事务并未提交，第二个线程又获得了该锁，导致数据出问题

@Transactional注解通过AOP实现事务管理，当标注该注解的方法执行完成后才提交事务，而synchronized代码块又是在一个事务内，就会出现第一个线程释放锁后但是事务还没提交，第二个线程就进入同步代码块获取到未提交的数据库数

@Transactional控制事务的范围比sychronized 大，如图：

解决@Transactional遇上@synchronized的生产问题

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

方法一：将锁替换成数据库的锁比如select for update或者版本号version
方法二：在service下将事务代码的抽取单独使用，无事务方法调用有事务的方法

既然问题出在事务未提交，那么只要把对应事务操作的代码单独抽取出来，封装成一个单独的方法，在synchronized中调用该方法即可

解决@Transactional遇上@synchronized的生产问题

@Service
public class OrderServiceImpl implements OrderServiceI {
	@Autowired
	private OrderDao orderDao;

	public sychronized Order updateOrder(int id) {  //加锁
		return updateOrderSafely(id); //调用数据库
	}

	@Transactional
	public Order updateOrderSafely(int id) {
		return orderDao.updateOrder(id);
	}
}

看起来好像是解决了事务未提交的问题，但会存在新的问题，可能会出现@Transactional事务不生效的情况

二、问题点 >》方法二引申：@Transactional事务不生效

在同一个类内部调用@Transactional标注的方法事务也不会开启，原因是：

@Transactional事务管理是基于动态代理对象的代理逻辑实现的，那么如果在类内部调用类内部的事务方法，这个调用事务方法的过程并不是通过代理对象来调用的，而是直接通过this对象来调用方法，绕过的代理对象，肯定就是没有代理逻http://www.devze.com辑了

方法：将锁提取到controller层，不包含任何事务

Controller类

 @RestController
 public class TestController {
     @Resource 
     private TestService testService;
     @PostMapping("/test")
     public synchronized void testInterface() {
          testService.functionA(); // 调用数据库操作方法
     }
 }

Service类

 @Service("testService")
 public class TestServiceImpl implements TestService {
    @Transactional(rollbackFor = Exception.class, 
                  propagation = Propagation.REQUIRES_NEW)
     public void functionA() {
         //数据库读写操作
     }
 }

注意点：

1、调用本类加@Transactional的方法时，要使用一个AOP对象来进行代理，获取到代理对象之后@Trasactional才会正常生效，否则是不生效的。

2、synchronized要比事务的粒度要大，否则还是会出现重复读的现象。

3、被调用的functionA为什么要使用 REQUIRES_NEW的隔离级别呢？因为这样就可以实现锁的粒度大于事务的粒度啦。无论如何，都创建新的事务，外层事务不受内层事务影响。但是有个问题，外层事务失败了，内层事务还是把记录入库了，有可能产生脏数据；

下面这段代码有什么问题呢？

Lock lock = new ReentrantLock();

@Transactional
public void save(){
    try{
        lock.lock();
        //业务代码……
    }finally{
        lock.unlock();
    }
}

1、显而易见就可以看出，Spring 会在方法开始时开启一个事务，并在方法结束时提交或回滚该事务。如果在方法内部手动加锁，可能会导致锁的持有时间超过事务的生命周期，这样可能会引发死锁或其他并发问题。

2、lock.lock()会阻塞线程，直至获取到锁为止，具体来说，如果锁已经被其他线程持有，调用 lock.lock() 的线程会被阻塞，直到持有锁的线程释放锁

还有值得注意的一点，很多人看到@Transactional和try&h编程客栈ellip;…在一起使用，就以为@Transactional会失效，其实并不是

①try-catch结构:

如果在try-catch块中捕获异常而不重新抛出，可能导致事务不按预期回滚。
解决方法：在@Transactional注解中指定rollbackFor属性，或者在catch块中重新抛出异常

②try-finally结构:

使用try-finally结构来确保资源释放（如锁的解锁）不会影响事务的正常行为，只要异常最终被抛出。
而上述代码用的是try-finally结构来确保锁的释放，这通常不会影响事务的正常行为。只要在业务代码中抛出的异常没有被捕获，事务就会按照预期回滚

因此应该修改成：

private final ReentrantLock lock = new ReentrantLock();

@Transactional(rollbjavascriptackFor = Exwww.devze.comception.class)
public void save() {
     if (!lock.tryLock()) {
          // 如果未能获取锁，可以记录日志或采取其他措施
          System.out.println("Failed to acquire the lock.");
          return; // 或者抛出异常
      }

      try {
        // 业务代码……
      } catch (Exception e) {
        // 处理异常
        throw e;
      } finally {
          lock.unlock();
      }
}